On Mon, Apr 13, 2020 at 1:32 AM <[email protected]> wrote: > > fstrim clears blocks, which currently are not in use and which > contents is != 0. >... > BUT: Clearing blocks is an action, which includes writes to the cells of > the SSD.
I see a whole bunch of discussion, but it seems like many here don't actually understand what fstrim actually does. It doesn't "clear" anything, and it doesn't care what the contents of a block are. It doesn't write to the cells of the SSD per se. It issues the TRIM command to the drive for any unused blocks (or a subset of them if you use non-default options). It doesn't care what the contents of the blocks are when it does so - it shouldn't even try to read the blocks to know what their content is. Trimming a block won't clear it at all. It doesn't write to the cells of the SSD either - at least not the ones being trimmed. It just tells the drive controller that the blocks are no longer in use. Now, the drive controller needs to keep track of which blocks are in use (which it does whether you use fstrim or not), and that data is probably stored in some kind of flash so that it is persistent, but presumably that is managed in such a manner that it is unlikely to fail before the rest of the drive fails. On a well-implemented drive trimming actually REDUCES writes. When you trim a block the drive controller will stop trying to preserve its contents. If you don't trim it, then the controller will preserve its contents. Preserving the content of unused blocks necessarily involves more writing to the drive than just treating as zero-fillled/etc. Now, where you're probably getting at the concept of clearing and zeroing data is that if you try to read a trimmed block the drive controller probably won't even bother to read the block from the ssd and will just return zeros. Those zeros were never written to flash - they're just like a zero-filled file in a filesystem. If you write a bazillion zeros to a file on ext4 it will just record in the filesystem data that you have a bunch of blocks of zero and it won't allocate any actual space on disk - reading that file requires no reading of the actual disk beyond the metadata because they're not stored in actual extents. Indeed blocks are more of a virtual thing on an SSD (or even hard drive these days), so if a logical block isn't mapped to a physical storage area there isn't anything to read in the first place. However, when you trimmed the file the drive didn't go find some area of flash and fill it with zeros. It just marked it as unused or removed its logical mapping to physical storage. In theory you should be able to use discard or trim the filesystem every 5 minutes with no negative effects at all. In theory. However, many controllers (especially old ones) aren't well-implemented and may not handle this efficiently. A trim operation is still an operation the controller has to deal with, and so deferring it to a time when the drive is idle could improve performance, especially for drives that don't do a lot of writes. If a drive has a really lousy controller then trims might cause its stupid firmware to do stupid things. However, this isn't really anything intrinsic to the concept of trimming. Fundamentally trimming is just giving the drive more information about the importance of the data it is storing. Just about any filesystem benefits from having more information about what it is storing if it is well-implemented. In a perfect world we'd just enable discard on our mounts and be done with it. I'd probably just look up the recommendations for your particular drive around trimming and follow those. Somebody may have benchmarked it to determine how brain-dead it is. If you bought a more name-brand SSD you're probably more likely to benefit from more frequent trimming. I'm personally using zfs which didn't support trim/discard until very recently, and I'm not on 0.8 yet, so for me it is a bit of a moot point. I plan to enable it once I can do so. -- Rich
