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

Hi Michael,

thank you for replying to my questions! :)

On 04/13 11:06, Michael wrote:
> On Monday, 13 April 2020 06:32:37 BST tuxic@××××××.de wrote:
> > Hi,
> >
> > From the list I already have learned, that most of my concerns regarding
> > the lifetime and maintainance to prolong it are without a
> > reason.
>
> Probably your concerns about SSD longevity are without a reason, but keep up
> to date backups just in case.  ;-)

...of course! :)
My question are more driven by curiousty than by anxiety...

> > Nonetheless I am interested in the technique as such.
> >
> > My SSD (NVme/M2) is ext4 formatted and I found articles on the
> > internet, that it is neither a good idea to activate the "discard"
> > option at mount time nor to do a fstrim either at each file deletion
> > no triggered by a cron job.
>
> Beside what the interwebs say about fstrim, the man page provides good advice.
> They recommend running a cron job once a week, for most desktop and server
> implementations.

...but it neither explains why to do so nor does it explain the technical
background.

For example it saus:
"For most desktop and server systems a sufficient trimming frequency  is
once  a week."

...but why is this ok to do so? Are all PCs made equal? Are all
use cases are equal? It even does not distinguish between SSD/Sata 
and SSD/NVMe(M2 in my case).

These are the points, where my curiousty kicks in and I am starting
to ask questions.

:)

> > Since there seems to be a "not so good point in time", when to do a
> > fstrim, I think there must also be a point in time, when it is quite
> > right to fstrim the mu SSD.
> >
> > fstrim clears blocks, which currently are not in use and which
> > contents is != 0.
> >
> > The more unused blocks there are, which has a contents != 0, the
> > lesser the count of blocks is, which the wear leveling algorithm can
> > use for its purpose.
>
> The wear levelling mechanism is using the HPA as far as I know, although you
> can always overprovision it.[1]

For example: Take an SSD with 300 GB user-useable space. To
over-overprovisioning the device the user decides to partitioning
only the half of the disk and format it. The rest is left untouched in
"nowhere land".
Now the controller has a lot of space to shuffle data around.
Fstrim only works on the mounted part of the SSD. So the used blocks
in "nowhere land" remain...unfstrimmed?

To not to use all available space for the partitions is a hint I found
online...and then I asked me the question above...

If what I read online is wrong my assumptions are wrong...which
isn't reassuring either.

>
> > That leads to the conclusion: to fstrim as often as possible, to keep the
> > count of empty blocks as high as possible.
>
> Not really.  Why would you need the count of empty blocks as high as possible,

Unused blocks with data cannot be used for wearleveling. Suppose you
have a total amount of 100 block, 50 blocks are used, 25 are unused
and empty, 25 are unused and filled with former data.

In this case only 25 blocks are available to spread the next write
operation.

After fstrim 50 blocks would be available again and the same amount of
writes could now be spread over 50 sectors.

At least that is what I read online...

> unless you are about to right some mammoth file and *need* to use up every
> available space possible on this disk/partition?
>
>
> > BUT: Clearing blocks is an action, which includes writes to the cells of
> > the SSD.
> >
> > Which is not that nice.
>
> It's OK, as long as you are not over-writing cells which do not need to be
> overwritten.  Cells with deleted data will be overwritten as some point.
>
>
> > Then, do a fstrim just in the moment, when there is no useable block
> > left.
>
> Why leave it at the last moment and incur a performance penalty while waiting
> for fstrim to complete?
 
Performance is not my concern (at least in the moment ;) ). I try to
fully understand the mechanisms here, since what I read online is not
without contradictions...

 
> > Then the wear-leveling algorithm is already at its limits.
> >
> > Which is not that nice either.
> >
> > The truth - as so often - is somewhere in between.
> >
> > Is it possible to get an information from the SSD, how many blocks are
> > in the state of "has contents" and "is unused" and how many blocks are
> > in the state of "has *no* contents" and "is unused"?
> >
> > Assuming this information is available: Is it possible to find the
> > sweat spot, when to fstrim SSD?
>
> I humbly suggest you may be over-thinking something a cron job running fstrim
> once a week, or once a month, or twice a month would take care of without you
> knowing or worrying about.

To technically overthink problems is a vital part of my profession and exactly what
I am asked for. I cannot put this behaviour down so easily. :)
From my experience there aren't too manu questions, Michael, there is
often only a lack of related answers.


> Nevertheless, if the usage of your disk/partitions is variable and one week
> you may fill it up with deleted data, while for the rest of the month you
> won't even touch it, there's SSDcronTRIM, a script I've been using for a
> while.[2]
>
>
> [1] https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm
> [2] https://github.com/chmatse/SSDcronTRIM

Cheers!
Meino