Back when the first good SSDs arrived 4-5 years ago, it became common knowledge that for best performance you should format the SSD with clusters aligned on 4KB boundaries, so they don't get split across flash pages.
But the current generation of SSDs uses 8KB or 16KB flash pages. Has anyone done a performance test to see if there are gains to be had by formatting with 8KB or 16KB clusters? The natural partition alignment yielded by Win7 or Win8 would still be good for this as by default the System partition created before your main C: partition is 100MB, so you actually have 4MB partition alignment (keeping to powers of 2). I would expect every current controller except Sandforce with its compression/hashing and handling of all kinds of wierd page sizes to see an improvement.
Does it improve write amplification and wear leveling as well? I would think it would since right now each 4KB write (ignoring buffering and write combining) must read an 8KB-16KB page, modify it, and write it back, so if you immediate write flushes are forced with only 4KB I/Os you get 2-4x write amplification with a perfect controller algorithm, but this issue could be insignificant in the real world from buffering and write combining, except in the case a file gets fragmented at a non 8KB boundary. And while it might be uncommon for a typical file, most large directories are probably fragmented in this manner. Also, I expect that using only partial pages due to having 4KB clusters on a larger page size will cause those partially used pages to ignore TRIM, because the firmware can't safely reuse the page when as far as it knows the other half of it might still be in use.
But the current generation of SSDs uses 8KB or 16KB flash pages. Has anyone done a performance test to see if there are gains to be had by formatting with 8KB or 16KB clusters? The natural partition alignment yielded by Win7 or Win8 would still be good for this as by default the System partition created before your main C: partition is 100MB, so you actually have 4MB partition alignment (keeping to powers of 2). I would expect every current controller except Sandforce with its compression/hashing and handling of all kinds of wierd page sizes to see an improvement.
Does it improve write amplification and wear leveling as well? I would think it would since right now each 4KB write (ignoring buffering and write combining) must read an 8KB-16KB page, modify it, and write it back, so if you immediate write flushes are forced with only 4KB I/Os you get 2-4x write amplification with a perfect controller algorithm, but this issue could be insignificant in the real world from buffering and write combining, except in the case a file gets fragmented at a non 8KB boundary. And while it might be uncommon for a typical file, most large directories are probably fragmented in this manner. Also, I expect that using only partial pages due to having 4KB clusters on a larger page size will cause those partially used pages to ignore TRIM, because the firmware can't safely reuse the page when as far as it knows the other half of it might still be in use.
Last edited:
Facebook
Twitter