Chris Kalin <chris.ka...@ibmilw.com> wrote: > It's also a decent idea to keep the total partition size under about 80% of > the total drive size so that you get the same write performance no matter how > full the partition gets. If partition size = drive size you'll start to see > massive slowdowns as the drive gets closer to 100%.
That's not actually true - or at least, very non-complete. All SSDs keep a pool of spare blocks - partly so they can keep a pool or erased blocks, partly so they have spare blocks to replace failing ones. As I wrote earlier, write performance tanks when the drive runs out of spare erased blocks - and that is a function of both the way you do writes and the size of the pool. So yes, if you leave unused space when you partition, then you will have a larger erased blocks pool **PROVIDED** that the unused space has never been used[1] [1] The drive "most likely" does not know about partitioning, and even if it did, it would be very dangerous to assume that any space not occupied by a partition was "fair game" to be erased since there may be other ways the space might be used (for example, the way Grub uses space before the first partition). So if the space has been used before, re-partitioning without somehow informing the drive that the excess space is now free, will not give any benefit. Adam Borowski <kilob...@angband.pl> wrote: > On any non-broken setup, as long as you trim in some way, it's stricly worse > to do that compared to using the full disk size but not letting the > filesystem get above 80% full. Modern filesystems (ie, not FAT) suffer > greatly when they're full to the brim ... I think there's a bit of tradeoff here. Bear in mind that even with trim, the free space in the filesystem may not be available for the drive to use. As I mentioned earlier, the drive uses considerably larger storage blocks than the OS - and unless all the space in one of those larger units is free, then none of it is available. After a quick look, I didn't find anything specific, but for one model of drive it has an erase block size of 1.5MByte. So all the 4k blocks within that 1.5M block must be marked as free before you gain anything from free space in the filesystem. I suspect that with some filesystems, there are options you could set that would tend to favour the right operations - having the filesystem work on the basis of 1.5M allocation units (until it has to split them to make space available) ought to do the trick as long as they are properly aligned. So as with many things, it's more of a "it depends". Leaving free space when partitioning will guarantee extra space usable by the drive for erased blocks - but will tend to promote a bit more fragmentation in the filesystem. I suspect that unless you really have very low utilisation (in which case having a smaller partition won't make any different to the filesystem) then I suspect most filesystems won't clump the free space together in a manner useful to the underlying drive. To further muddy the waters, AIUI the drive can set bits, but not clear them. Hence if it needs to write a small chunk of data into an already part used storage block, it may be able to do so if the part it needs to write to is still blank. So **in theory** it would be possible for the drive to (in the background) move part used storage blocks around so that any known free space within it is in the erased state - so it can opportunistically write into free space in the middle of a block should the host ask it to. I suspect this would have high overheads and a possibly low hit rate - I have no idea if any drives actually do this. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
