[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Whole Disk Encryption + SSD



On 7/2/21 8:02 AM, David Wright wrote:
On Thu 01 Jul 2021 at 20:43:09 (-0700), David Christensen wrote:
On 7/1/21 7:55 PM, David Wright wrote:
On Mon 28 Jun 2021 at 13:36:35 (-0700), David Christensen wrote:

I do not set the 'discard' (trim) option in fstab(5).  If and when I
want to erase unused blocks (such as before taking an image), I use
fstrim(8).

What improvement does erasing unused blocks achieve?

Zero blocks are readily compressed, reducing the size of the image file.

Ah, I see. So a spinning rust analogy might be:

. Take an old conventional disk, sdz, where df shows 10% uasge,
. cp /dev/zero a-file-on-sdz
. rm a-file-on-sdz
. dd if=/dev/sdz … and compressing it, saving ~90% space.

But can I tweak my question a little—

Say that /dev/sdz contained one partition, sdz1, which filled the disk
and was a LUKS encrypted /home. In this case, the above would fail to
save space because the raw device sdz would be full of "random" data.

But what happens with an SSD? If, after the rm step above, you
# fstrim /home
the mountpoint, where /etc/fstab has the line
   /dev/mapper/luks-fedcba98-7654-3210-… LABEL1 ext4 /home
then what gets zeroed, the container or the contained?
I can't put my finger on any documentation that spells it out.


AIUI userland programs such as fstrim(8) interact with the kernel via an application programming interface (API). Device drivers interact with the kernel and/or each other via device driver interfaces (DDI). Some device drivers are designed to interact with hardware. Other device drivers are designed to fit in between the kernel and/or device drivers -- for example, LVM, md, and dm-crypt. So, you can layer ext4 on top of LVM on top of dm-crypt (LUKS) on top of md on top of several SSD's.


Given a file system driver that supports trim, fstrim makes an API call to the file system driver telling the file system driver to erase unused blocks. The file system driver knows what blocks are unused and makes DDI calls to trim those blocks. If everything between the file system driver and the SSD(s) supports trim commands, eventually the trim commands reach the SSD(s) and blocks are erased. Similarly, the response codes must be passed upwards from the SSD(s) to the file system driver, which then responds to fstrim.


David


Reply to: