> Anyway, that 20-33% left entirely unallocated/unpartitioned > recommendation still holds, right?
I never liked that idea. And I really disliked how people considered it to be (and even passed it down as) some magical, absolute stupid-proof fail-safe thing (because it's not). 1: Unless you reliably trim the whole LBA space (and/or run ata_secure_erase on the whole drive) before you (re-)partition the LBA space, you have zero guarantee that the drive's controller/firmware will treat the unallocated space as empty or will keep it's content around as useful data (even if it's full of zeros because zero could be very useful data unless it's specifically marked as "throwaway" by trim/erase). On the other hand, a trim-compatible filesystem should properly mark (trim) all (or at least most of) the free space as free (= free to erase internally by the controller's discretion). And even if trim isn't fail-proof either, those bugs should be temporary (and it's not like a sane SSD will die in a few weeks due to these kind of issues during sane usage and crazy drivers will often fail under crazy usage regardless of trim and spare space). 2: It's not some daemon-summoning, world-ending catastrophe if you occasionally happen to fill your SSD to ~100%. It probably won't like it (it will probably get slow by the end of the writes and the internal write amplification might skyrocket at it's peak) but nothing extraordinary will happen and normal operation (high write speed, normal internal write amplification, etc) should resume soon after you make some room (for example, you delete your temporary files or move some old content to an archive storage and you properly trim that space). That space is there to be used, just don't leave it close to 100% all the time and try never leaving it close to 100% when you plan to keep it busy with many small random writes. 3: Some drives have plenty of hidden internal spare space (especially the expensive kinds offered for datacenters or "enthusiast" consumers by big companies like Intel and such). Even some cheap drivers might have plenty of erased space at 100% LBA allocation if they use compression internally (and you don't fill it up to 100% with in-compressible content). -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
