Re: [gentoo-user] Understanding fstrim...

[Michael]

On Monday, 13 April 2020 12:39:11 BST Rich Freeman wrote:
> On Mon, Apr 13, 2020 at 1:32 AM <tuxic@××××××.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.