On Monday, 13 April 2020 12:39:11 BST Rich Freeman wrote: > On Mon, Apr 13, 2020 at 1:32 AM <tu...@posteo.de> 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.
What Rich said, plus: I have noticed when prolonged fstrim takes place on an old SSD drive of mine it becomes unresponsive. As Rich said this is not because data is being physically deleted, only a flag is switched from 1 to 0 to indicate its availability for further writes. As I understand the firmware performs wear-leveling when it needs to in the HPA allocated blocks, rather than waiting for the user/OS to run fstrim to obtain some more 'free' space.
signature.asc
Description: This is a digitally signed message part.
