F17 and Discard (TRIM) support on LUKS/dm-crypt devices

[Japplo]

Hi guys,
how can I enabled the discard option on LUKS/dm-crypt devices?

Thanks japplo

[Japplo]

cat /etc/crypttab
luks-23a640d0-0132-4189-8459-7ede9812fe3d UUID=23a640d0-0132-4189-8459-7ede9812fe3d none,discard

doens't work in F17... any idea's?

[Puff65537]

cat /etc/crypttab
luks-23a640d0-0132-4189-8459-7ede9812fe3d UUID=23a640d0-0132-4189-8459-7ede9812fe3d none,discard

doens't work in F17... any idea's?

Did you remember to use dracut to create a new initramfs with the new crypttab in it?

[StephenH]

Why are you putting it in your cryptab? Why not in fstab, which is the place I have seen referenced to using the discard option in every guide I have seen?

/dev/mapper/luks-90.............f6 / ext4 defaults,noatime,discard 1 1

See these threads for more information:

http://forums.fedoraforum.org/showthread.php?t=256068
http://forums.fedoraforum.org/showthread.php?t=277082

[Japplo]

@Puff65537 doesn't work for me. I have a workaround using the dm-table, but this is not very easy to handle
@StephenH I'm using a luks/dm-crypt device. Only add the discard option in the /etc/fstab is not enough. http://www.fedoraforum.org/forum/sho....php?p=1511682 and cryptsetup status luks-23a640d0-0132-4189-8459-7ede9812fe3d shows me, that discard is not avaible

[StephenH]

When I look at the /etc/crypttab file, I see the reference to the LUKS is associated with the UUID and none.
Here is an example (edited)

luks-eb9... ... ... ...f3 UUID=eb9... ... ... ... ...f3 none

There are four such entries, one for each of the encrypted partitions on my drive. I do not use LVM, so each partition is separate.

In my fstab file, I see this for my desktop system, which is on a standard HD:

/dev/mapper/luks-eb9... ... ... ... ...f3 /home ext4 defaults 1 2

In my fstab for the netbook which is on an SSD, the only difference is the addition to make the equivalent line read defaults,noatime,discard.

Now, the ext4 file system is handled by the fstab. The cryptab is just the container, but once it is unlocked, would not the trim be handled by the fstab entry since we are looking at a file system operation? My subjective experience with the SSD in this netbook seems to indicate that fstab is the appropriate place as I have not noticed the slowdown that some indicate is an issue when the trim option is not used.

I have now been using this SSD configured as I said for a number of weeks. Previously, the Read-Only Benchmark by the Disk Utility had minimum read rate of 184.4, maximum 270.6 and average of 240.4 MB/s. I just did another test, and the testing is very close to that, 183.5, 269.4, and 237.8 MB/s, respectively with repeated test coming in at around the same figures (with minor variations).

I really did not see anything in the link you posted to indicate that changing the crypttab file is needed. Post #8 in that thread claimed that the filesystem commands were not passed through to the drive. If that were the case, then it would seem that once a space on the SSD were allocated by the filesystem, then the underlying filesystem's usage would be permanently locked in the crypttab and it would be shown as allocated. However, if I delete a large file (or set of files), I can see the results when I execute a df command. The space is apparently being freed up. My drive is apparently able to use the trim command in the fstab to keep things working well, and my experience with this OCZ Vertex Plus drive is quite satisfactory.

Disclaimer: I am not an engineer, just a satisfied user and am relaying my subjective experience, not technical information. I am willing to be shown that I am wrong and that something is needed in the crypttab. However, there is nothing compelling so far in the other thread to prove that case. "As far as I know..." is far from definitive.

[dismuter]

The cryptab is just the container, but once it is unlocked, would not the trim be handled by the fstab entry since we are looking at a file system operation? My subjective experience with the SSD in this netbook seems to indicate that fstab is the appropriate place as I have not noticed the slowdown that some indicate is an issue when the trim option is not used.

My 2 cents:
As you said fstab gives file system options, so deleting files on ext4/Btrfs/XFS will trigger a discard command. However that discard command will hit the next layer, which in your case is the LUKS/dm-crypt layer. If that layer is not given instructions to re-issue discard commands to lower levels when it receives them, then there will be no trimming (discarding) on your SSD. Same goes for the LVM layer, for which discard commands can be activated in /etc/lvm/lvm.conf by setting issue_discards to 1.
All in all, I don't think your SSD is receiving any TRIM command if you haven't done anything about enabling discard on your encryption layer.


Now I too have a problem with enabling discard upon boot-up on Fedora 17. I modified /etc/crypttab to add "discard" to the fourth column and ran 'dracut -f' to rebuild initramfs, I checked that the new crypttab was properly copied to it, but running 'dmsetup table' after a reboot shows no sign of discard being activated.
I tried the same changes on Ubuntu 12.04 ('dracut -f' changed to 'update-initramfs -u') and they worked without a hiccup. The difference in Ubuntu is that /etc/crypttab includes a "luks" option in the fourth column.
So what is the proper way of enabling discard on LUKS/dm-crypt on F17?

cat /etc/crypttab
luks-23a640d0-0132-4189-8459-7ede9812fe3d UUID=23a640d0-0132-4189-8459-7ede9812fe3d none,discard

doens't work in F17... any idea's?

Unless I'm mistaken, it should be "none discard" at the end, no comma. But that doesn't work for me under Fedora.

---------- Post added at 01:03 PM ---------- Previous post was at 09:24 AM ----------

Well, it looks like it's simply an omission from /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh, hence the following comment:

TODO: improve to support what cmdline does

I'll look at where to manually add the --allow-discards flag to cryptsetup in dracut's crypt module. It'll do on my side until someone more proficient fixes that.

Edit: this works:

[]# diff cryptroot-ask-orig.sh cryptroot-ask.sh
108c108
< --ply-cmd "$luks_open -T1 $device $luksname" \
---
> --ply-cmd "$luks_open -T1 $device $luksname --allow-discards" \
111c111
< --tty-cmd "$luks_open -T5 $device $luksname"
---
> --tty-cmd "$luks_open -T5 $device $luksname --allow-discards"

[Puff65537]

That worked

[Japplo]

I think it doesn't work for me because with "cryptsetup status luks-xxx" the discard flag is missing. Are you using F17?

[StephenH]

My 2 cents:
As you said fstab gives file system options, so deleting files on ext4/Btrfs/XFS will trigger a discard command. However that discard command will hit the next layer, which in your case is the LUKS/dm-crypt layer. If that layer is not given instructions to re-issue discard commands to lower levels when it receives them, then there will be no trimming (discarding) on your SSD. Same goes for the LVM layer, for which discard commands can be activated in /etc/lvm/lvm.conf by setting issue_discards to 1.
All in all, I don't think your SSD is receiving any TRIM command if you haven't done anything about enabling discard on your encryption layer.

I can understand that. However, fixing it is a different matter then.

Now I too have a problem with enabling discard upon boot-up on Fedora 17. I modified /etc/crypttab to add "discard" to the fourth column and ran 'dracut -f' to rebuild initramfs. . .
So what is the proper way of enabling discard on LUKS/dm-crypt on F17?

Well, it looks like it's simply an omission from /usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh, hence the following comment:

I'll look at where to manually add the --allow-discards flag to cryptsetup in dracut's crypt module. It'll do on my side until someone more proficient fixes that.

Edit: this works:

Well, this didn't work for me with F16. It left me with a system that would not recognize the password and just kept giving me a message about discard not being supported.

I thought I had destroyed my working setup, but just booting to the previous kernel, then uninstalling the newest one where I had done the change (which deleted the initramfs which didn't work) and then reinstalling it got things back to normal.

I think I'll wait until the upstream support is there before I mess with this again. As I said, I have not noticed any slowdown with only having the trim support enabled in fstab, even if crypttab is not passing it through. Maybe this summer when I have more time I can try again, especially after F17 is released.

[Puff65537]

For performance reasons you have to run fstrim by hand. My setup has the following mods:

/etc/cryptsetup : "none discard" at the end of all lines on an ssd
/usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh : all lines using "luks_open" also have --allow-discard (note that you have to fix this every time dracut is updated).
/etc/fstab: noatime,discard added to all ssd files systems.

initfs rebuilt after all the changes

after all that I still run "time fstrim -v /<ssd filesystem>" by hand when I'm ready for the performance hit (note: time isn't needed, but it will show you why they don't auto-trim).

[Japplo]

Hello Puff65537,
can you show me a "cryptsetup status luks-xxx | grep flag" ?

[Puff65537]

I show:
" flags: discards"

[Japplo]

Crazy, and are you using F17?

[Puff65537]

I did change /etc/issue not to say beefy miracle (that was too whack for me), but other than that its F17-TC2 + all updates. Note that I did zero out my MBR and LVM volumes from the previous F16 so I could get the new kernel to auto-align them with the ssd blocks.

edit: from x86-64 install DVD