The partitioner "guided partitioning" offers me:

 - use the largest continuous free space
 - use entire disk
 - use entire disk and set up LVM
 - use entire disk and set up encrypted LVM

I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Also once I start partitioning, eg, "and set up LVM", I can't delete the
partitions again.  Well, I can, but I have to switch to a terminal,
run dmsetup remove_all.  Which sometimes confuses the partitioner and it
gets stuck printing "??? ???"  If that happens, I can neither "go back",
nor "continue".

Alternatively, the installer allows to reserve free space in the
encrypted volume group.

The installer allows to delete logical volumes, volume groups and
unencrypted partitions formerly used as physical volumes, but not
encrypted volumes nor their underlying partitions.

That does not accomplish my goal of extending the life of my SSD.  The
SSD will see those blocks as "in use" because they have encrypted data
written to them (it cannot tell that they are encrypted blocks of zeroes
because, well, they're encrypted).

The unused area has to be part of the unencrypted disk.  And then I have
to call TRIM on it.

Yes.  This is a poor experience.

Not if you do not write anything to them, or if you TRIM them.

You may either
- tell the installer not to erase (=write) the encrypted partition (if
guided partitioning prompts it, not sure)
or
- enable "discard" in /etc/crypttab (should be the default)
- create a logical volume in the free VG space
- blkdiscard the logical volume

Irrelevant. Once written, even with plaintext zeroes, a block is
considered used until it is TRIMmed.

commit 0c659b82d11e
Author: Matthew Wilcox <willy@infradead.org>
Date:   Thu Apr 2 10:37:25 2009 -0400

    ata: Add TRIM infrastructure

Last time I checked, dm-crypt did not pass DISCARD requests through to
the underlying device because it's a security hazard.

AFAICS dm-crypt and cryptsetup have supported discard since Linux 3.1.

crypttab(5) states that "starting with Debian 10 (Buster), this option
is added per default to new dm-crypt devices by the Debian Installer".

Discard can still be disabled at the filesystem or swap level, or you
can disable dm-crypt discard after running blkdiscard.

Matthew Wilcox <willy@infradead.org> writes:

Can one achieve this by telling LVM to allocate less than the full size
of the device to the PV one puts on it?

If one does that, I would guess that one could later extend the PV to
use more/all of the disk using pvresize, so that those that prefer space
over endurance could make that decission when they are running out of
space.

If that's all true, we could have a couple of preseed variables to set
the percentage and maximum amount that would be left fallow for this
purpose, and (eventually) set non-zero defaults when installing to SSD.

Is that something like what you're after?

Cheers, Phil.

AFAIK partman does not support it. But guided partitioning allows to
reserve some free space in the VG, which achieves the same goal.
not need to resize the PV when you need to use the free space.

But both ways have the same issue with Matthew's use case: when/if
partman-auto-crypto erases (=writes with random data) the whole
underlying LUKS partition, all its blocks are marked "in use" by the SSD.