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

[Mathwiz]

On 9/6/2019 at 2:25 AM, 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.

With that insight, along with the fact that the number of reserved sectors in a FAT32 volume defaults to 32, it occurred to me that if I could just "round up" the number of FAT sectors to the nearest multiple of 32, then both FATs and the data clusters area would all be 16KiB-aligned!

So with that in mind, I downloaded the source code to mkdosfs, made that change (turned out to be a one-line fix), and recompiled it with VS2010. And it works:

The key is that the FATs are 27344 sectors long vs. the 27333 sectors calculated by the original version.

(BTW, the Linux code in mkdosfs will auto-select FAT32 - you don't have to specify "-F 32" if the volume is 512MiB or larger - but that change was never ported to the Win32 code, so I did that too "while I was at it.")

CrystalDiskMark indicates that aligning the FATs in this manner doesn't make a noticeable difference, but it may not tell the full story. It creates test files, then measures sequential and random read/write speeds to them, so the FAT doesn't get updated while the benchmark tests run.

I looked online for a program to benchmark file system operations, as opposed to raw read/write speeds, but didn't find much. There is a program called Iozone, but it's a very complex command-line program with very little help or documentation, so I couldn't figure out how to use it.

Edited September 27, 2019 by Mathwiz