TRIM for XP

[Milkinis]

On 10/21/2023 at 7:06 PM, reboot12 said:

 

I have a NVMe 970 disk like the author of the topic.

XP doesn't actually need a NVMe drive

you only need to know what registry parameters slow it down.

I have a ''broken'' XP partition in a old HDD with tens of tools installed and it really flies I feel it faster than Win7 in a SSD

I open a folder with lots of pics and they all load instantantly it's really impressive.

[Dixel]

4 hours ago, Milkinis said:

XP doesn't actually need a NVMe drive

you only need to know what registry parameters slow it down.

I have a ''broken'' XP partition in a old HDD with tens of tools installed and it really flies I feel it faster than Win7 in a SSD

I open a folder with lots of pics and they all load instantantly it's really impressive.

Overall, I agree with you, still with an SSD XP will be even more responsive, if properly configured.

Win7 does way too many reads-writes, especially at startup, also agree.

[Mark-XP]

Please let me expand this topic e little bit:

About a dacade ago i was informed that standard partitioning an ssd in Win7 would respect the (physical 4k) sector alignment. Ever since, i partitioned a new ssd with Win7 diskmgmt.msc (even if XP allways inhabits the primary partition for sure) and never had any problems at all.

Now lately i anstalled a Linux besides WinXP and Win7 an ran "sudo fdisk -l". The diagnosis was somewhat scary:

me@compi:~\> sudo fdisk -l
Disk /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectors
...
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *           63  67135634  67135572    32G  7 HPFS/NTFS/exFAT
/dev/sda2        67135635 713173544 646037910 308,1G  f W95 Ext'd (LBA)
/dev/sda5        67135698 377559629 310423932   148G  7 HPFS/NTFS/exFAT
/dev/sda6       377559693 465660089  88100397    42G  7 HPFS/NTFS/exFAT
/dev/sda7       465660153 625073084 159412932    76G  7 HPFS/NTFS/exFAT
/dev/sda8       625073148 713173544  88100397    42G  7 HPFS/NTFS/exFAT
/dev/sda3       713173545 763604991  50431447    24G 83 Linux
/dev/sda4       763604992 771993599   8388608     4G 82 Linux swap / Solaris

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.
Partition 6 does not start on physical sector boundary.
Partition 7 does not start on physical sector boundary.
Partition 8 does not start on physical sector boundary.

(sda1: primary WinXP partition,  sda2: extended partition housing sda5: Data ... sda8: Win7)

Obviously almost nothing is aligned here (except the Linux swap) which doesn't surprise much, since Win7-diskmgmt did put the first primary part at sector 63 (and not 64).

What practice would you recommend for bringing into servive and partitioning a new ssd?

Edited December 20, 2023 by Mark-XP
typo

[jaclaz]

Well, for whatever reason your initial partitioning did not respect the "new" paradigm (that - just for the record - is not sector 64 but rather sector 2048).

If you are dual booting XP and 7 you risk (unknowingly) to lock yourself out of all the logical volumes inside extended:

http://reboot.pro/index.php?showtopic=9897

(if you are using the "new" alignment AND use the XP disk management, once you have parittioned with the new alignment NEVER use the XP disk management on that disk/ssd)

The old paradigm was "align to cylinder" (hence 63) while the new one is "align to Mbyte" (hence 2048 as 2048x512=1048576).

The setting for this behaviour is - since Vista - in the Registry, it is a set of four keys in CurrentControlSet (that could be ControlSet001 or ControlSet002):

HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\LessThan4GB

HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\Between4_8GB

HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\Between8_32GB

HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\GreaterThan32GB

The defaults are 1048576 for the last three and 65536 (128x512=65536) for the first one, for smaller devices, as said it started with Vista and all later Windows use the same, here are some details for Server 2008:

https://frankdenneman.nl/2009/05/20/windows-2008-disk-alignment/

The 64 sector offset was used by a few hard disks, but is not common.

Check that you have these keys with the default values in your Registry, then if you partition normally using Windows 7 Disk Management the partition will have the "new normal" 2048 alignment.

jaclaz

[Mark-XP]

4 hours ago, jaclaz said:

Well, for whatever reason your initial partitioning did not respect the "new" paradigm (that - just for the record - is not sector 64 but rather sector 2048).

If you are dual booting XP and 7 you risk (unknowingly) to lock yourself out of all the logical volumes inside extended:

Grazie @jaclaz, esatto: it's a dual-boot situation (initially, then with linux later grub gets installed to get it triple-boot).

The "new" paradigm you're mentioning is the GPT partitioning scheme - with its 2048 sector patition table.

No, for whatever reason i never thought about switching to GPT (instead of traditional MBR) - does Win-XP (32bit) have any problems with it? And, more importantly: is GPT a precondition for achieving correct sector alignment on an ssd?

Regarding those registry-entries: in Win7 i have two of them (ControlSet001 and ControlSet002)) with equal values:  65536 for "LessThan4GB"  and  1048576 for the other 3. 

[Mark-XP]

Yes, of course; inserting a pristine ssd in the 2nd drive-slot, Win7's diskmgmt shows up the "data-media-initialising" tool where i first have to choose between the traditional MBR and modern GPT (with a 2048 s GUID).

Well, as a (technical) ultraconservative (blimp?) i obviously ever choosed MBR here.

The second important reason is: i'm using a (licensed) version of xxClone for easy cloning and backuping my WinXP and Data partitions. Furthemore, if anything goes wrong with notorious Win7 or Linux regarding boot: this longterm faithful ,companion' is able to copy the MBR back again  onto the affected hd/ssd in a second - and i can boot back to ,safe harbour' WinXP .

A possibility i see (a priori): one could stay with MBR but then choose a size for the primary (WinXP) patition to let it end precisely at the end of a physical sector , and then - at least - all the subsequent partitons could be sized to be aligned.

Is that correct?

[jaclaz]

4 hours ago, Mark-XP said:

The "new" paradigm you're mentioning is the GPT partitioning scheme - with its 2048 sector patition table.

 

 

No, no, no.

Partition alignment has nothing to do with partitioning style.

It is not particularly smart to have a GPT disk aligned to cylinder (i.e. with 63 sectors before first partition) but it is technically possible, as in most implementation of GPT at the most 32 sectors are used for the GPT Partition Table (which is not 2048 sectors) the GPT uses:

LBA 0 Protective MBR
LBA1 GPT header

LBA2 - 33 Partition entries (each takes 128 bytes so 32x4=128 max number of partitions)

So 34 sectors for the whole stuff.

Windows VIsta and later when partitioning will align to 2048 sectors INDEPENDENTLY from the style (MBR or GPT) you choose.

You DO NOT want to use GPT:

GPT is not compatible with BIOS and it is not compatible with XP booting, ONLY use MBR.

You can have alright a MBR style partitioning with Mbyte alignment BUT you should NOT use EVER the XP disk management IF you have on the disk logical volumes inside extended.

The XP disk management has no issues with primary partitions, only logical volumes inside extended are at risk.

jaclaz

 

[Mark-XP]

2 hours ago, jaclaz said:

Windows VIsta and later when partitioning will align to 2048 sectors INDEPENDENTLY from the style (MBR or GPT) you choose.

You DO NOT want to use GPT:

GPT is not compatible with BIOS and it is not compatible with XP booting, ONLY use MBR.

Thank you @jaclaz you're absolutely right, and sorry for my missunderstading:

Did an initializing with a pristine ssd and part.style MBR in Win7 (see jpeg below), created a primary partition, and it starts correctly at sector 2048:

me@compi:~\> sudo fdisk -l
Disk /dev/sdb: 465,76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x01b2403d

Device     Boot    Start       End   Sectors  Size Id Type
/dev/sdb1           2048  67151871  67149824   32G  7 HPFS/NTFS/exFAT
/dev/sdb2       67167765 377591759 310423995  148G  f W95 Ext'd (LBA)
/dev/sdb5       67167828 377591759 310423932  148G  7 HPFS/NTFS/exFAT

Partition 2 does not start on physical sector boundary.
Partition 5 does not start on physical sector boundary.

But anyway - according to linux' fdisk the subsequent partitions are not aligned physically - not if created with diskmgmt, nor if i use EASUS Partition Master 9.0.  In either case fdisk tells me there's no correct physical sector alignment.

How should one create and manage windows' partitions then?

Edit: Or is there something special with "fdisk"? Does "aligned to 2048 sectors" not mean the same as "physical sector alignment" (are there two different types of sectors)?

Edited December 21, 2023 by Mark-XP

[George King]

@Mark-XP It would be interesting to perform same test with Windows Server 2003 SP2 x86 as Windows XP x64 SP2 boots "fine" in UEFI from GPT disk partitioned by Windows 7 x64 setup.

These builds should come from same source tree, so there is a chance 2003 x86 can do it instead of XP. And probably can be done by disk.sys + partmgr.sys from 2003

[Mark-XP]

28 minutes ago, George King said:

@Mark-XP It would be interesting to perform same test with Windows Server 2003 SP2 x86 as Windows XP x64 SP2 boots "fine" in UEFI from GPT disk partitioned by Windows 7 x64 setup.

Sorry @George King, neither WS 2003 nor XP-x64 here to test their boot-compatibilty in UEFI/GPT environment. And tbh, @jaclazhas even strengthend above my decision to stay with Bios/MBR.

Btw.: horrible news from Prague yesterday, sad to hear - even the ,golden city' isn't safe from such adversity these days...

[jaclaz]

I cannot say "why" you have that situation, but you have a hole between sdb1 and sdb2.

Please follow me.

sdb1 starts on sector 2048 (right)

it is 67149824 sectors in size which is evenly divisible by 8 (as the device has a physical sector of 4096 bytes it is 8 x 512 bytes or 8 logical sectors),  disk management/diskpart normally creates "rounded to megabyte" partitions and 32788x1024x1024/512=.67149824 so this is also "right".

sdb2 starts on 67167765 but, (and this is "queer") before it you have 2048+67149824=67151872 so WHAT is this hole of 67167765-67151872=15893 sectors?

sdb2 is a an extended partition, the unused sectors for the extended partition would anyway normally be - again - 2048m so everything would remain alignedm but sdb2 has an odd number of sectors, 310423995, which make no sense to me, unless this extended has been aligned to the cylinder (I just checked it is, it virtually starts at CHS 4181/0/1 and end - like the logical volume inside it - at CHS 23503/254/63).

Also, sdb5 is the actual logical volume inside extended, but it starts at 67167828 and 67167828-67167765=63 which is the "old" offset.

So, it seems to me like you used the "new" Windows 7 partitioning for just the first partition and then you used XP (or another "old" convention tool) to create the extended and the logical volume in it.

jaclaz

 

Edited December 22, 2023 by jaclaz
corrected a mis-calculation

[Mark-XP]

3 hours ago, jaclaz said:

I cannot say "why" you have that situation, but you have a hole between sdb1 and sdb2. ...

sdb2 starts on 67167765 but, (and this is "queer") before it you have 2048+67149824=67151872 so WHAT is this hole of 67167765-67151872=15893 sectors?

Grazie mille di nuovo @jaclaz per l'assistenza! That "queer hole" was the result of  a hapless collaboration of three:

1. MS for sure: with Win7 they eliminated the possibility to create an extended partition in diskmgmt ,

2. myself - because i didn't inform me well that it remains still possible: with cmd-line diskpart. And instead used:

3. Easus Partition Master 9 - which creates an extendend partition automatically - but obviously that extra "hole" in addition.

It looks much better now, without any warning:

Disk /dev/sdb: 465,76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1            2048  67147775  67145728    32G  7 HPFS/NTFS/exFAT
/dev/sdb2        67147776 976771071 909623296 433,7G  f W95 Ext'd (LBA)
/dev/sdb5        67149824 377577471 310427648   148G  7 HPFS/NTFS/exFAT
/dev/sdb6       377579520 465680383  88100864    42G  7 HPFS/NTFS/exFAT
/dev/sdb7       465682432 629297151 163614720    78G  7 HPFS/NTFS/exFAT
/dev/sdb8       629299200 721614847  92315648    44G  7 HPFS/NTFS/exFAT

Now only remains the final task to shrink the extended Part sdb2 (so that it finishes with sdb8 - to gain the space for linux) - i didn't find that option in Win7's diskmgmt neither... (i hope not to be forced to use gparted to achieve this during linux installation process, i'm allways near to a heart attack at that point...)

[jaclaz]

I don't think that disk management/diskpart will allow you to  shrink that partition.

Personally I would use directly a hex/disk editor, but of course it isn't advisable if you are not familiar with one or you don't want to waste some time learning how to use one.

In case you are interested, since you are also running XP[1], I would suggest you good ol' Tiny Hexer, optionally with my MBR view script:

http://reboot.pro/index.php?showtopic=8734

Your mission, should you accept it , is to change four bytes in the partition table (second entry):

976771071=FF57383A

should become

721614847=FFF7022B

so, actually, three bytes.

jaclaz

[1] it should work just fine in Windows 7, but if I recall correctly Windows 7 has a mechanism to protect the MBR so - again if I recall correctly - the disk needs to be put offline (or maybe it was the PBR that had this protection? )

[Mark-XP]

Thanks again @jaclaz for your gentle invitation to hack the partition table, but after thinking about it for some minutes and having found the domain mirkes.de abandoned (vendesi) i decided to solve it practically and shrinked the ext. Partition with gparted in a minute (no heart attack though since it's still ,empty'):

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1            2048  67147775  67145728    32G  7 HPFS/NTFS/exFAT
/dev/sdb2        67147776 721614847 654467072 312,1G  f W95 Ext'd (LBA)
/dev/sdb5        67149824 377577471 310427648   148G  7 HPFS/NTFS/exFAT
/dev/sdb6       377579520 465680383  88100864    42G  7 HPFS/NTFS/exFAT
/dev/sdb7       465682432 629297151 163614720    78G  7 HPFS/NTFS/exFAT
/dev/sdb8       629299200 721614847  92315648    44G  7 HPFS/NTFS/exFAT

No, one cannot figure out that ssd-procedure: initialize it in Win7, with diskmgmt, switch to diskpart to create the ext.partition, then back into diskmgmt to create the 4 ,logical drives' and finally boot to linux and shrink the ext.partition with gparted...

Grazie e buone feste!

And sorry @Dietmar for having hijacked your thread for a while

[jaclaz]

Yep, it is now an old software, still available (as an example) on Softpedia:

https://www.softpedia.com/get/Others/Miscellaneous/tiny-hexer.shtml

 

jaclaz