Re: "hardware-assisted zeroing"

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Tue, Jan 04, 2022 at 05:37:05PM -0500, Eric Levy wrote:
> On Tue, 2022-01-04 at 15:49 -0500, Zygo Blaxell wrote:
> 
> > Cheap SSD devices wear out faster when issued a lot of discards mixed
> > with small writes, as they lack the specialized hardware and firmware
> > necessary to make discards low-wear operations.  The same flash
> > component
> > is used for both FTL persistence (where discards cause wear) and user
> > data (where writes cause wear), so interleaved short writes and
> > discards
> > cause double the wear compared to the same short writes without
> > discards.
> > The fstrim man page advises not running trim more than once a week to
> > avoid prematurely aging SSDs in this category, while the discard
> > mount
> > option is equivalent to running fstrim 2000-3000 times a day.
> 
> It seems much of the discussion relates to the design of physical
> hardware. I would need to learn more about SDD to understand why the
> operations are useful on them, as my thought had been that they would
> be helpful for thin-provisioned logical volumes, but not meaningful on
> physical devices.
> 
> I wonder whether the same or a different set of concerns from the ones
> raised would be most helpful when considering management of non-
> physical devices.

You'll still have the locked block groups with the discard mount option,
whether those are good or bad for your workload.

There are two main categories of trim command:  one that guarantees a
particular data value when reading from previously trimmed blocks, and
one that makes no such guarantee (i.e. it may leave the data unchanged,
filled with garbage, or any other contents).

The first kind is usually equivalent to at least one page write,
because it can't be reordered or dropped, and opportunities to merge
are strictly limited, but it must be persisted.

The second kind is much faster since no persistent write is required
to implement the trim itself.  The thin volume can merge the trim with
later writes that update persistent data, or persist the trim in a
background thread without blocking data writes.

This distinction holds for SSDs and also thin volumes (or caching volumes,
or in general any software, including drive firmware, that exists below
the filesystem layer).  The lower layer also usually controls which set
of trim semantics are available to the upper layer.