Re: [gentoo-user] "Amount" of fstrim? (curiosity driven, no paranoia :)

[Rich Freeman]

On Mon, Apr 27, 2020 at 12:20 PM <tuxic@××××××.de> wrote:
>
> The kernel is keep track of all, which already has been fstrimmed and
> avoids to retrimm the same data.
> This knowledge gets lost, when the PC is powercycled or rebooted.
>

I imagine this is filesystem-specific.  When I checked the ext4 source
I didn't think to actually check whether those flags are stored on
disk vs in some kind of cache.

I wouldn't be surprised if this data is also lost by simply unmounting
the filesystem.

> I think, the value of the amount of fstrimmed data does not reflect
> the amount of data, which gets physically fstrimmed by the SSD
> controller.

Yup.  Though I'd take issue with the term "physically fstrimmed" - I
don't think that a concept like this really exists.  The only physical
operations are reading, writing, and erasing.  TRIM is really a
logical operation at its heart.

It wouldn't make sense for a TRIM to automatically trigger some kind
of erase operation all the time.  Suppose blocks 1-32 are in a single
erase group.  You send a TRIM command for block 1 only.  It makes no
sense to have the device read blocks 2-32, erase blocks 1-32, and then
write blocks 2-32 back.  That does erase block 1, but it costs a bunch
of IO and it only replicates the worst case scenario of what would
happen if you overwrote block 1 in place without trimming it first.
You might argue that now block 1 can be written later without having
to do another erase, but this is only true if the drive can remember
that it was already erased - otherwise all writes have to be preceded
with reads just to see if the block is already empty.

Maybe that is how they actually do it, but it seems like it would make
more sense for a drive to try to look for opportunities to erase
entire blocks that don't require a read first, or to try to keep these
unused areas in some kind in extents that are less expensive to track.
The drive already has to do a lot of mapping for the sake of wear
leveling.

Really though a better solution than any of this is for the filesystem
to be more SSD-aware and just only perform writes on entire erase
regions at one time.  If the drive is told to write blocks 1-32 then
it can just blindly erase their contents first because it knows
everything there is getting overwritten anyway.  Likewise a filesystem
could do its own wear-leveling also, especially on something like
flash where the cost of fragmentation is not high.  I'm not sure how
well either zfs or ext4 perform in these roles.  Obviously a solution
like f2fs designed for flash storage is going to excel here.

-- 
Rich