Can Windows XP Pro x86 *Safely* TRIM an SSD?

[Mathwiz]

Getting back to the original topic, I was intrigued by the discussion of FAT32 alignment. So I ran a couple of tests with a 64GB SanDisk Ultra flash drive plugged into a USB 2.0 port.

First, I formatted it with GUIFormat.exe, a popular freeware FAT32 disk format utility. Then I ran the CrystalDiskMark6 benchmark on it:

Not very impressive, but I was only using a USB 2.0 port.

Next, I reformatted with RMPrepUSB, which aligns the clusters with the flash drive's (presumed) 4K sectors, and ran another benchmark (with the same USB 2.0 port):

OK, that's only about a 5-10% improvement in random read speed, but a 40% improvement in random write speed, and a whopping 50% improvement in sequential write speed! With this alignment, FAT32 actually out-benchmarks (slightly) NTFS! Pretty impressive and clearly worth doing if you need a FAT32-formatted flash drive or AF hard drive.

Edit: Rezeroing the flash drive (easily done with "format i: /p:1" on Windows Vista or later; WinXP unfortunately does not recognize the /p switch) before formatting with RMPrepUSB produced a bit more improvement:

... although the read speeds dropped a bit from last time, so the previously noted improvement may have been a fluke.

Of course, the improved write speeds probably won't last as the flash drive fills up again, but if you're formatting, you might as well start with the drive as fast as possible.

Edited September 3, 2019 by Mathwiz

[jaclaz]

Yep, what you report is on the "high" side but in any case the improvement is substantial.

In the topic that more or less started it all JFYI:

pointertovoid registered smaller increases, though at the time he did it manually, whilst with Steve6375 (Author of RMPRPUSB) several slightly different approaches were tested at the time (and of course the fastest one chosen), again JFYI: 

http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/

jaclaz

[exogenesis]

17 hours ago, Mathwiz said:

Getting back to the original topic, I was intrigued by the discussion of FAT32 alignment. So I ran a couple of tests with a 64GB SanDisk Ultra flash drive plugged into a USB 2.0 port.

First, I formatted it with GUIFormat.exe, a popular freeware FAT32 disk format utility. Then I ran the CrystalDiskMark6 benchmark on it:

Not very impressive, but I was only using a USB 2.0 port.

Next, I reformatted with RMPrepUSB, which aligns the clusters with the flash drive's (presumed) 4K sectors, and ran another benchmark (with the same USB 2.0 port):

OK, that's only about a 5-10% improvement in random read speed, but a 40% improvement in random write speed, and a whopping 50% improvement in sequential write speed! With this alignment, FAT32 actually out-benchmarks (slightly) NTFS! Pretty impressive and clearly worth doing if you need a FAT32-formatted flash drive or AF hard drive.

Does using exFAT improve this over FAT32 or even maybe improve the read, write speed over NTFS

[jaclaz]

20 hours ago, exogenesis said:

Does using exFAT improve this over FAT32 or even maybe improve the read, write speed over NTFS

I don't think anyone tested this approach on exFAT, where most probably it is not needed (as it is not needed for NTFS, though for dfferent reasons).

But from these tests here:

https://www.flexense.com/fat32_exfat_ntfs_usb3_performance_comparison.html

it's not like there are any sensible increases in speed with exFAT.

And BTW we don't know if the FAT32 in those tests were "properly" aligned or not,, most probably they were not, so if you take into account the recorded increases in speed obtained by properly aligning the FAT32 volume, the exFAT will come out as slower than FAT32 (and it has already been found slower than NTFS in most cases).  

As a side-side note the specifications for exFAT were just released by MS:

https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification

Since there is actually a FatOffset Field and a ClusterHeapOffset Field :

Quote

3.1.6 FatOffset Field

The FatOffset field shall describe the volume-relative sector offset of the First FAT. This field enables implementations to align the First FAT to the characteristics of the underlying storage media.

Quote

The ClusterHeapOffset field shall describe the volume-relative sector offset of the Cluster Heap. This field enables implementations to align the Cluster Heap to the characteristics of the underlying storage media.

it is very likely that (at least using MS tools) exFAT volume contents are properly aligned already.

Most we had till now was some reverse engineering (just for the record):

https://www.sans.org/reading-room/whitepapers/forensics/reverse-engineering-microsoft-exfat-file-system-33274

that (understandably) didn't enter in the actual use of the alignment fields and areas.

Also a filesystem that may be worth a couple tests is the rarely mentioned UDF, which is built-in since Vista, it seems like noone ever properly tested it against FAT/exFAT, the only one I could find:

https://www.sami-lehtinen.net/blog/exfat-extended-file-allocation-table-vs-udf-universal-disk-format-file-system-for-flash-drives

seems leading to much faster reads but slower writes, so I guess using the one or the other really depends on a case by case basis.

jaclaz

 

 

[Mathwiz]

5 hours ago, jaclaz said:

3.1.6 FatOffset Field

The FatOffset field shall describe the volume-relative sector offset of the First FAT. This field enables implementations to align the First FAT to the characteristics of the underlying storage media.

Strange they even bothered with this, since FAT32's "reserved sectors" effectively served the same purpose. It would've made more sense to add a way to align the Second FAT - and of course the cluster heap, which they did add and which is the most important thing to align by far.

As for the overall value of exFAT, I haven't seen much. It does allow files >= 4GB, and it seems to be correctly aligned; aside from that, the only benefit I can find is to Microsoft, who patented exFAT so they could charge royalties for using it. But the net effect was only to ensure that manufacturers of cheap electronic devices often don't support exFAT, requiring FAT32 or NTFS instead; yet, most large USB flash drives now come formatted with exFAT, and have to be reformatted for use with said cheap electronics.

[jaclaz]

Well, to be picky as usual, no.  

In theory the "perfect alignment" in FAT32 (in volume) needs TWO "corrections":
1) Number of reserved sectors to align the first FAT
2) Size of FAT 1 (multiple of alignment) to align 2nd FAT and contents

What is still up to debate is whether to align contents or "contents - Label" when both are not aligned with the same value and the actual alignment value to choose (that may offer better performance if aligned to the "erase page size" of the specific device.

With exFAT, the  equivalent of #1 is represented by the FatOffset Field (i.e. both touching the reserved sectors in FAT32 and putting a value in the FatOffset field in exFAT result in shifting the beginning of the FAT)

And the equivalent of #2 is the  ClusterHeapOffset.

Still in theory in exFAT there is ONLY one FAT (in TexFAT there are two, as well as two bitmaps):

Quote

3.1.16 NumberOfFats Field

The NumberOfFats field shall describe the number of FATs and Allocation Bitmaps the volume contains.

The valid range of values for this field shall be:

1, which indicates the volume only contains the First FAT and First Allocation Bitmap

2, which indicates the volume contains the First FAT, Second FAT, First Allocation Bitmap, and Second Allocation Bitmap; this value is only valid for TexFAT volumes

How actually that is implemented in practice might be an entirely different topic.

jaclaz

[dencorso]

Observe that ouf riends at Ridgecrop Consultants make the source of fat32format available and tell us it compiles with MSVS 6.0, so that adding an option for the command line version to align FAT32 should be possible and it even might be possible to interest them on doing it themselves. But, at the moment, @jumper also has a working setup for compiling things with MSVS 6.0, so he also might become interested in creating an experimental version of it. 

[Mathwiz]

16 hours ago, jaclaz said:

Still in theory in exFAT there is ONLY one FAT (in TexFAT there are two, as well as two bitmaps):

Well, if there's only one FAT, then they just renamed "reserved sectors" to "FAT offset," but it means the same thing: the number of sectors between the start of the partition and the first/only FAT. Then they added the cluster heap offset so both the FAT and clusters could be properly aligned.

In FAT32 the cluster heap offset doesn't exist, and the reserved sectors defaults to 32, which aligns the first FAT, but usually misaligns the second FAT and the clusters. By tweaking the reserved sectors, you can choose instead to align the second FAT, or the clusters, but usually at most one of the three.

In theory you could achieve a triple alignment in FAT32 by choosing the partition size nicely, so that each FAT contained a multiple of 8, 16, etc. sectors. But short of that, experimentation with a "tweakable" FAT32 formatter like mkdosfs shows that aligning the clusters is by far the best choice. So I suspect there's little performance difference between exFAT filesystems (with both FAT and clusters aligned) and cluster-aligned FAT32 filesystems. Getting rid of the redundant second FAT may help exFAT a little, and the new bitmap probably speeds things up a little more, but they're not going to make a huge difference.

16 hours ago, jaclaz said:

What is still up to debate is whether to align contents or "contents - Label" when both are not aligned with the same value and the actual alignment value to choose (that may offer better performance if aligned to the "erase page size" of the specific device.

I noticed that RMPrepUSB does this "hanging" alignment, aligning cluster 2 on a 1 MB boundary. (Thus, cluster 1, with the volume label, hangs off the start of the 1 MB page and is located at the end of the previous page, along with the tail end of the second FAT. That 1 MB page would be rarely updated as long as the drive doesn't get too full.) That may help with some older flash drives, but it didn't make any noticeable difference with mine compared to a simple cluster-aligned format done manually with mkdosfs. I think it's because newer flash drives have "smart" controllers that remap the 4K physical sectors to different 4K internal sectors, so 1 MB alignments don't really matter: with all the mapping, there's no way to predict which 4K sectors belong to the same 1 MB page. (Besides, unless the flash drive has been nearly filled up, most of the slow read-erase-rewrite operations are done by a garbage collection algorithm when the flash drive is idle, so they don't degrade performance as long as the drive has plenty of zeroed sectors for the garbage collector to work with.) So I doubt 1 MB alignments are worth the trouble, at least with newer flash drives.

Edit: Ignore the struck-through references to "cluster 1" containing a volume label above. Cluster 1 does not actually exist on a FAT volume. The rest of the paragraph is OK, AFAIK.

Still, with years of flash drives out there, with all their different technologies, there are probably a few somewhere that are helped by 1 MB alignment. So as usual, YMMV.

Edited September 5, 2019 by Mathwiz

[dencorso]

Now I'm confused: AFAICR, the volume label on a FAT32 cannot exceed 11 characters (upercase letters, numbers or underscore only) and do exist starting at offset 0x47 in the PBR (with a second copy at 0xC47, which is not always updated) and as a 32-bytes (short-)entry in the root directory pointing nowhere and having 0-size (which, of course, can be forced to be the 1st entry). So, then, what do you mean by "1st cluster" containing the volume label? Since when the volume label occupies *any* cluster? Can any of you shine some light on my deep puzzlement? TIA.    

===============
Unless one is assuming the root directory will always be at cluster # 2 (not necessarily true) and that the root directory always will fit in a single cluster (not necessarily true, either), although both assumptions can be true when the whole disk is created at once, say, by RMPrepUSB. Is that it?

 

[Mathwiz]

I can help a little with the root directory: in FAT32 it's just like any other directory or file - a linked list of clusters - except there's a pointer to the first cluster in the BPB. See offset 0x2C at https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FAT32_Extended_BIOS_Parameter_Block. FAT32 format utilities generally set this pointer to 2, the first cluster that actually exists on the volume, but strictly speaking, you're right; they don't have to.

The volume label reference I made above is apparently wrong. There was some misleading discussion at reboot.pro that implied Cluster 1 exists: they kept referring to the "first" cluster, which I misread as meaning cluster 1, but actually cluster doesn't exist at all and the "first" cluster they were referring to is cluster 2. I'll edit my last post to fix that mistake.

I think what threw me off was this sentence:

Quote

I allow for the volume name entry which is why the 8 sector discrepancy.

(emphasis added), which I read as referring to an 8-sector "cluster 1" with only the volume name (and a whole lot of wasted space), but now I think it refers to cluster 2, with the volume name and the first several root directory entries.

Anyway, the discussion was whether to put that "first" cluster at the end of a 1 MB page or the start of the next one. The thinking appeared to be: since it only holds the volume label and the first several root directory entries, it wouldn't change often and so shouldn't be placed in the same 1 MB page as the presumably more "dynamic" data clusters that followed it.

But, since 1 MB alignment doesn't seem to matter (at least with the drive I tried) the whole discussion is moot AFAIAC.

Edited September 5, 2019 by Mathwiz

[dencorso]

2 hours ago, Mathwiz said:

I can help a little with the root directory: in FAT32 it's just like any other directory or file - a linked list of clusters - except there's a pointer to the first cluster in the BPB. See offset 0x2C at https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#FAT32_Extended_BIOS_Parameter_Block. FAT32 format utilities generally set this pointer to 2, the first cluster that actually exists on the volume, but strictly speaking, you're right; they don't have to.

Sure. I had that info in mind when I started to object. So, the 1st cluster of the root dir is at boot_sector:0x02C and if the FAT entry for that cluster says 0x0FFFFFFF (= End of cluster Chain aka EoC), then the root directory is just 1 cluster long (which can perfectly mean 64 sectors of 512 bytes). And in case all entries in the root dir fit and it never grows, then the alignment at the 2nd cluster (provided boot_sector:0x02C = 2) may make sense. That's ifs galore, don't you agree?

BTW, just in case you're having a bout of insomnia, you might like this old thread:

 

[Mathwiz]

To make things even more confusing, the thread I was reading, at http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/ sometimes refers to cluster 3 as the "first data cluster" and cluster 2 as simply the root directory, as if we were back in the FAT16 days!

Quote

Here are test results for FAT32 format variations

FORMAT 1 = RMPrepUSB 2.1.647 - First data cluster aligned to 1MB
FORMAT 2 = FAT Table aligned to 1MB
FORMAT 3 = Root Dir aligned to 1MB
FORMAT 4 = RMPrepUSB 2.1.630 - no alignment

Times below are for xcopy of 1122 small files repeated 3 times on freshly formatted drive (so 2nd and 3rd time is overwriting the files)
Times in seconds - repeated test returns result within 0.5 seconds, ie. they are reproducible (AV was turned off during testing)

F1 F2 F3 F4
45 47 44 50 copy to freshly formatted USB 3 Flash drive
34 41 36 42 overwrite same files
35 42 37 42 overwrite again

This shows F1 and F3 are the best. F3 is best (slightly) when writing to a fresh FS, but F1 is best when overwriting files on an existing FS.

I guess that terminology makes some sense: root directories don't often get very large, so most FAT32 volumes probably do have a relatively static, one-cluster-long root directory at cluster 2, everything else being files and subdirectories. But it sure got me confused.

Incidentally, I was surprised there was any speed difference at all between the poster's F1 and F3 formats (even though the difference is small), but as I said, YMMV; it could be the specific flash drive he tested with, or even a quirk of where the FATs ended up in the two variations and not related to the 1 MB alignment at all.

At any rate, if you need to use FAT32 I do recommend the RMPrepUSB program; it's free and will give your USB flash or AF drive a well-performing, aligned FAT32 format, without making you do any math!

[jaclaz]

@dencorso

The "label" in the bootsector is in practice ignored by most OS's, what counts is the label (as an effect of the label command or similar)  that is - and here comes one of the ifs you appreciate could be 0x08 or 0x28  depending on the specific OS formatting the filesystem.

https://msfn.org/board/topic/154648-dos-format-b-and-label/?tab=comments#comment-984466@Mathwiz

Quote

BTW I found while checking another couple "strange" things.

ALL DOS versions tested have an attribute of the label as 0x28 (i.e. Archive+Label), whilst XP uses the 0x08 (Label Only).

This has a nice side effect.

If you access the floppy image with 7-zip you can actually see the LABEL, it's created date & time, modified date & time and the last accessed date.

XP, though it writes 0x08 treats the 0x28 just as the 0x08, i.e. somehow the 0x08 is "prevailing" on the 0x20 

@Mathwiz

There is a post I made to try and clear the matter ( the good MS guys sometimes are not being capable to write plain English):

http://reboot.pro/topic/16783-rmprepusb-faster-fat32-write-access-on-flash-memory-drives/?p=153550

The point about the label applies only if the label is applied first thing after (or during) formatting (or however before the number of files entries fill cluster 2), it applies in the case of RMPREPUSB, but if you do not use the label or apply  it after having copied to the filesystem a sufficient number of files of course it won't be inside first cluster (of the file and directory data region).

About FAT size/alignment, there is no rule written in stone that the FAT area must actually correspond EXACTLY to the amount of FAT entries needed.

Imagine a (completely hypothetical) filesystem with 1000 clusters.

You will need no less than 1000 32 bit (or 4 bytes) entries in (each) FAT.

So roughly (for the sake of simplicity let's ignore the leading "lost" bytes) you need 1000x4 bytes 4000 bytes for the FAT, but you cannot have less than 8 sectors, i.e. 7*512=3584 < 4000 < 8x512 = 4096, which means that you have 96 more bytes than needed.

What if instead of an 8 sectors FAT you use instead a 9 sector (one)?

Nothing, i.e. you will have 512+96=608 excess cluster address space (that will be ignored just like the 96 in the previous example) and the volume/filesystem will work just fine.

So, if the "normal" format will produce - say - a 785 sectors sized FAT, nothing prevents you from "extending" it to - still say - 800 sectors, thus making it an exact multiple of 8 sectors.

This way, if the "Reserved sectors" are already a multiple of 8 sectors, the first FAT is also a multiple of 8 sectors and so is the second FAT, with the result that everything, including the "file and directory data region" are aligned to 8 sectors.

But, since there are 2 FATs, you can only have cluster 2 aligned (and not cluster 3, i.e. jumping over the cluster where the "label" and the actual "virtual" root directory is), the only way would be to create a given number of (fake/empty) directories to fill cluster 2 and 3 and have the actual files start on cluster 4 (which would result in a "mess"),  of course if cluster size is compatible with the alignment that doesn't matter. 

jaclaz

 

Edited September 6, 2019 by jaclaz

[Mathwiz]

7 hours ago, jaclaz said:

There is a post I made to try and clear the matter ( the good MS guys sometimes are not being capable to write plain English)

I have a theory that OS-level programmers only have nine fingers. Why else would they always start counting at zero?

6 hours ago, jaclaz said:

The point about the label applies only if the label is applied first thing after (or during) formatting (or however before the number of files entries fill cluster 2)

Right. One could, of course, fill up the first cluster of the root directory then add a volume label, but I guess in the thread, the unstated assumption was that the volume label would be applied during formatting; hence the reference to the 8-sector-long "volume name entry" that got me so mixed up.

6 hours ago, jaclaz said:

About FAT size/alignment, there is no rule written in stone that the FAT area must actually correspond EXACTLY to the amount of FAT entries needed.

I like that idea: having "extra" sectors in the FAT rather than (or in addition to) tweaking the number of reserved sectors. I don't think there's as much advantage in aligning the FATs as in aligning the clusters, but it can't hurt, and if you left the reserved sectors at the default 32, but then rounded up the FAT size to the next multiple of 32, then everything (both FATs and all the clusters) would be aligned on 16K boundaries, which would be good enough for just about every flash drive.

I'm dubious about the advantage of 1 MB alignment, but if you wanted to do 1 MB alignment, with clusters 2 & 3 "split" between 1 MB pages, you could do it like this:

• Make the number of reserved sectors equal to the cluster size (which in turn is at least the drive physical sector size; usually 4K)
• Make the FAT size a multiple of 2048 sectors (1 MB) minus the size of one cluster

Now the reserved sectors plus the first FAT fit in a whole number of 1 MB pages, the second FAT plus cluster 2 fit in the same number of 1 MB pages, cluster 3 is at the start of the next 1 MB page, and of course every structure is aligned on a cluster size (4/8/16/32/64K) boundary.

For smaller volumes (e.g., 512 MB up to 4 GB or so), you could make the FAT size 1024 sectors minus the size of one cluster, saving 1 MB. Then everything through and including cluster 2 would be on the first 1 MB page, and again cluster 3 would be at the start of the next 1 MB page.

Has something like this been tried and compared to, say, RMPrepUSB's FAT32 format? (I doubt it would make much difference, but at least it's elegant!)

[jaclaz]

Well it is not that difficult to experiment manually.

Just use a "normal" format command (without applying a label).

See what comes out by default.

Then (if needed) increase  the Reserved Sectors value (in the bootsector).

Then (if needed) increase the FAT size (again in the bootsector) .

Then copy the  first sector of the first FAT to the shifted beginning. (or just write F8 FF FF 0F FF FF FF FF FF FF FF 0F  to the shifted first sector)

Unmount and remount.

Run CHKDISK /F on the volume, reply no to saving lost chains.

As a side note, and curiously enough, the backup bootsector is not updated by running CHKDSK, but the second FAT table is alright.

Quick experiment with an IMDISK volume 50 MB in size:

BEFORE:

Quote

 

C:\>chkdsk F:
Il file system è di tipo FAT32.
Numero di serie del volume: C06C-0E31
Verifica dei file e delle cartelle in corso...
Verifica dei file e delle cartelle completata.
Verifica del file system effettuata.  Nessun problema rilevato.

   51.605.504 byte di spazio totale su disco.
   51.604.992 byte disponibili su disco.

          512 byte in ogni unità di allocazione.
      100.792 unità totali di allocazione su disco.
      100.791 unità di allocazione disponibili su disco.

 

Changed with Tiny Hexer (only "random" changes without any calculation behind):

Reserved sectors 32 -> 34

Fat Size 788->800

And written F8 FF FF 0F FF FF FF FF FF FF FF 0F to sector LBA 34

Unmounted and re-mounted, AFTER:

Quote

C:\>chkdsk F: /F
Il file system è di tipo FAT32.
Numero di serie del volume: 1C63-693E
Verifica dei file e delle cartelle in corso...
Verifica dei file e delle cartelle completata.
Convertire i concatenamenti persi in file (S/N)? n
1536 byte liberati su disco.
Correzioni apportate al file system.

   51.592.192 byte di spazio totale su disco.
   51.591.680 byte disponibili su disco.

          512 byte in ogni unità di allocazione.
      100.766 unità totali di allocazione su disco.
      100.765 unità di allocazione disponibili su disco.

 

jaclaz