Ytdyklly

I have a LUKS partition /dev/sda1 which I luksOpen with --allow-discards:

cryptsetup --allow-discards luksOpen /dev/sda1 root

I then mount the ext4 filesystem with discard option:

grep /dev/mapper/root /proc/mounts

/dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0

I then trim free space on the mounted partition:

fstrim -v /

with df, I see / has 80% free space.
That means that on /dev/sda1, 80% of the disk are binary zeros.

If I clone the image with cat

cat /dev/sda1 > sda1.img

and compress the image with xz, I would expect all the zeros on the disk to be compressed. Since the 20% of the data on the disk is encrypted, it should look like random and be uncompressible. Therefore, the xz-compressed image should be aprox. 20% of the raw size.

However, the resulting xz-compressed image is approximately same size as the raw original.

Is my reasoning correct?

Why does not my theory translate into practice ?

Your logic is not incorrect. But it is only valid if some conditions are satisfied.

The TRIM command, as specified in the ATA command set, may or may not zero the sectors it is issued against.

Actually, the standard focuses on what data has to be returned after TRIM has been issued¹:

The follow behaviors are specified by this standard for sectors that the device trims (see 7.5.3.3):

a) non-deterministic - the data in response to a read from a trimmed sector may change for each read until the sector is written by the host;

b) Deterministic Read After Trim (DRAT) - the data returned in response to a read of a trimmed sector does not change, but may be different than the data that was previously returned; and

c) Read Zeroes After Trim (RZAT) - the data returned in response to a read of the trimmed sector is zero.

[...] For both DRAT and non-deterministic storage devices, the data returned in response to a read command to an LBA that has been successfully trimmed:

a) may be the previously returned data for the specified LBA;

b) may be a pattern generated by the storage device; and

c) is not data previously written to a different LBA by the host.

Thus, what your device returns after fstrim depends on the features it implements. Unless it supports RZAT, the assumption that data read from a trimmed device will be only zeros does not hold.

You can use hdparm to check for this:

sudo hdparm -I /dev/sdX | grep -i trim

I performed some tests using two SSDs, sda and sdb. Same manufacturer, different models, with different ATA conformance:

$ sudo hdparm -i /dev/sdb

 ...

 Drive conforms to: Unspecified:  ATA/ATAPI-3,4,5,6,7

 ...



$ sudo hdparm -i /dev/sda

 ...

 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 ...

The two SSDs have different support for TRIM:

$ sudo hdparm -I /dev/sda | grep -i trim

           *    Data Set Management TRIM supported (limit 1 block)



$ sudo hdparm -I /dev/sdb | grep -i trim

           *    Data Set Management TRIM supported (limit 8 blocks)

           *    Deterministic read ZEROs after TRIM

I can confirm that, after issuing fstrim, the drive supporting "Deterministic read ZEROs after TRIM" (RZAT) seems to have actually zeroed the concerned partition almost entirely. Conversely, the other drive seems to have zeroed (or otherwise replaced with some highly compressible pattern) only a minor part of the freed space.

¹_{Online source: INCITS 529: Information technology - ATA/ATAPI Command Set - 4 (ACS-4)}

Note on testing:

As pointed out by frostschutz in comments, a read after fstrim may return data from the operating system cache, and not from the trimmed device. It is, for instance, what happened in this qustion.

(I would also point to this answer to the same question for an alternative method for testing TRIM).

Between fstrim and a subsequent read you may need to drop the cache, e.g. with:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Depending on the size of the partition you are playing with, not dropping the cache may be enough for your tests to fail.

Note on your setup:

The discard mount option enables continuous TRIM, i.e. any time files are deleted. It is not required by fstrim. Indeed, on-demand TRIM and continuous TRIM are two distinct ways to menage TRIM operations. For further information I would point to Solid state drive on the Arch Linux Wiki, which has a detailed coverage of this matter.

Does the SSD have a built-in hardware encryption layer? If it has one, then the TRIMmed blocks may be all-zeroes (or possibly all-ones) at the raw hardware level, but since the computer sees them through the encryption layer, they will appear as pseudo-random gibberish after passing the all-zeroes raw block through the decryption process.

Such a hardware encryption layer would have some advantages:

• It would allow very fast security erase functionality: just have the drive destroy the original key used in the hardware encryption layer and replace it with a new one and all data will be instantly unrecoverable for most practical purposes.


• As all the data hitting the raw hardware level would be encrypted, it would be guaranteed to look pseudo-random and thus be largely homogenous. This might help to avoid hot/cold spots and simplify wear estimation a lot.

Discard is not the same as Zero.

If you want to zero with cryptsetup you could shrink the fs then the crypt block then dd the unused volume space.

If you want to know if trim worked doing a speed test should be an indicator after heavy use.

https://linux.die.net/man/8/fstrim
https://en.m.wikipedia.org/wiki/Trim_(computing)

df reporting free space does not imply zeroed space.

trim tells the storage device that the blocks are un-used. I don't think that this zeros them.