Re: Bug#869897: [debian-installer] Please add support for the TRIM command for SSDs

["Henrique de Moraes Holschuh" <hmh@hmh.eng.br>]

On Wed, Jan 22, 2020, at 02:49, Witold Baryluk wrote:
> The dmcrypt / LUKS doesn't enable discard by default on purpose, as it might
> potentially be a security issue. I don't think personally it is actual
> security problem, but it is just my personal opinion. You would need to
> convince dmcrypt / luks maintainer to change the default probably.

It is not just that.  DISCARD/TRIM is final, if we have it enabled on LVM or in the partitioner, there is no possible data recovery if you get things wrong, as they would issue a block discard to certain areas of the disk.

And it is not obvious which areas would they erase, either.  Will LVM discard a PV when you pvcreate? Or the backing areas of a LV on a LV remove? Or both?   Will the partitioner discard the non-assigned areas (which is different from assigned to do-not-touch areas) of the block device?  Or the ones you told it to create a filesystem on top?  Or both?

As I said, it is *not* obvious.  You'd actually have to look up documentation carefully to know the answers to the above questions.

> BTW. As of the moment kernel and ext4 and LVM doesn't detect automatically
> if the device is discard (TRIM) capable, and doesn't use it by default,
> which is rather missfortunate.

Oh, they *do* detect and issue discards() when supported *IF* you enabled discard.  The default is *no* discard, however, for very good reasons that are still valid to date.

For filesystems on regular ssd, it has been known for a LONG time that fstrim is the safer -- and faster -- option, for anything short of nvme and thin-provisioned storage (VM thing, not related to SSDs), and maybe even there.

For block device areas you want to clean, it should be an explicit command. "discard unpartitioned space", "discard this partition" on the partitioners.

For filesystems, it makes sense to wipe the backing device using trim before writing the fs structures, so at least that can be done automatically as a safe default for mke2fs, mkxfs and the like.  Same goes for compound commands that create a LV (or partition) and write a filesystem to it, etc.

My point is: discard support is nice when OPTIONAL and DEFAULTING TO DISABLED.  In any other case, it is a can of data-loss worms.    We could have it as an expert option, and we could do it without asking in the scenarios where previous data wiping is certain (when you get to the point that you will actually "write a filesystem to partition FOO *now*").

On dmcrypt/LUKS, it is just one layer of "worse" to have it enabled by default...

-- 
  Henrique Holschuh