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

[Rich Freeman]

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.

-- 
Rich