Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

You can easily check if TRIM works for a "normal" ext4 partition: http://askubuntu.com/a/19480/5920.

How to do that for a LUKS-encrypted one? Let's assume the default LUKS setup made by 12.04 Alternate installer (i.e. the one with LVM involved).

Update

What I'm asking here is how I can check that the block on the disk is actually filled with zeros after removing the file, if the file is stored in an encrypted volume.

share|improve this question
add comment

3 Answers

This was answered in the question you linked.

If you are using LVM, you need to add discard to the options in /etc/fstab

Open /etc/fstab with any editor

# Command line
sudo -e /etc/fstab

# Graphical
gksu gedit /etc/fstab

Add in "discard" to the options in the 4th column.

/dev/mapper/volumegroup-root  /  ext4  discard,noatime,nodiratime,errors=remount-ro  0  1

You then add in the same option (discard) to /etc/crypttab

Assuming your LUKS partition is /dev/sda1 (adjust accordingly)

# Command line
sudo -e /etc/crypttab

# Graphical
gksu gedit /etc/crypttab

Again, add in discard:

sda1_crypt UUID=[... series of numbers ...] none luks,discard

Update your initramfs

sudo update-initramfs -c -k all

Reboot

Confirm TRIM is working ...

sudo dmsetup table /dev/mapper/sda1_crypt --showkeys

You should see "allow_discards" in the output

For additional information, see : http://worldsmostsecret.blogspot.com/2012/04/how-to-activate-trim-on-luks-encrypted.html

share|improve this answer
    
Thanks for the answers, but I meant a different thing in my question, sorry for the lack of clarification. Check my updated question. FYI sudo dmsetup table /dev/mapper/sda1_crypt --showkeys returns allow_discards, but I'd like to check if the disk is actually TRIM-ed. –  Tomasz Zieliński Jul 11 '12 at 18:17
add comment

I don't have dm-crypt with TRIM setup yet, but I'm also interested in verifying this. First it should be said that this might not be possible, depending on your SSD (see: http://serverfault.com/a/401506/60525).

Assuming you have the right kind of SSD, I see a couple different options:

  1. Test this on a very small block device. Create a 20Mb encrypted partition just as you would for your whole system. Make sure to first fill the partition with random bytes. Then create, write, flush, and delete a 10Mb file on the encrypted fs. Run fstrim on the mounted fs. If everything is working, you should see about half the 20Mb partition filled with zero bytes.

  2. Alternatively you could verify that either the UNMAP or WRITE SAME scsi command is being issued through the scsi subsystem. The only way that I found to see the scsi packets without using a hardware device or hacking the kernel was to turn on logging of scsi packets:

    echo $BITMASK > /sys/module/scsi_mod/parameters/scsi_logging_level

    Using 9216 as the BITMASK was enough for me to see WRITE SAME cdbs being send after an fstrim of an ext4 fs residing directly on disk (no encryption).

    You could use either fstrim at the fs level or sg_unmap/sg_write_same at the device level to trigger a TRIM. Once you find either UNMAP or WRITE SAME, use the scsi docs at t10.org to decode the packet and figure out what disk block its referring to. Then check that the disk has all zeroes at that sector(s).

The latter approach is more arduous, but it has the advantage of working on pre-existing installs and is much easier when working with non-trivially sized filesystems. You may find it sufficient to see the UNMAP or WRITE SAME command being sent (do you really care if there are zeros or not?) Note that the latter approach will likely not work if the TRIM is done via the ata DATA SET MANAGEMENT command, it shouldn't show up in the scsi log and I see not way to get ata cdbs. But I'd bet that's less than .01% of the cases.

The latter solution could be some what automated, that way we wouldn't have to decode the packet by hand. Any takers?

And as far as I now there's no way to get a mapping of encrypted block address to device block address without hacking dm-crypt.c So if you're looking to see that the blocks of a deleted file on a trimmed fs on the encrypted block device map to zero sectors on the device, you're in for a world of pain.

share|improve this answer
    
Interesting ideas! I'll try them when I have some time to spend :) –  Tomasz Zieliński Aug 9 '12 at 8:42
add comment

I don't see how TRIM can work at all for an encrypted volume ; the volume is, by definition, full of random-looking (ie - non zero) data. TRIM zeroes blocks when the file system no longer has active data stored on them. In an encrypted volume, what is stored on the hardware block device is not a file system, but a virtual block device.

share|improve this answer
1  
Well, it works. But I'd like to see those zeros myself :) –  Tomasz Zieliński Jul 11 '12 at 18:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.