Description of problem: Fresh install of F18 on SSD, I can find no trace of trim working. I am using encryption. Version-Release number of selected component (if applicable): Latest everything as of today. cryptsetup-1.5.1-1.fc18.x86_64 Steps to Reproduce: # dmsetup table /dev/mapper/luks* | grep allow (nothing) # lsblk -D NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 1 ├─sda1 0 512B 2G 1 └─sda2 0 512B 2G 1 └─luks-X (dm-0) 0 512B 2G 0 ├─fedora_X-swap (dm-1) 0 512B 2G 0 ├─fedora_X-root (dm-2) 0 512B 2G 0 └─fedora_X-home (dm-3) 0 512B 2G 0 sdb 0 0B 0B 0 └─sdb1 0 0B 0B 0 └─luks-X (dm-4) 0 0B 0B 0 sr0 0 0B 0B 0 # cryptsetup status /dev/mapper/luks*|grep flag (nothing) # grep discard /etc/lvm/lvm.conf issue_discards = 1 The "discard" option is present in /etc/fstab. I have rebuilt initrd using dracut -fv. Additional information: Expected this to be automatic by now...
TRIM will never be supported by default for encrypted block devices. (see http://asalor.blogspot.cz/2011/08/trim-dm-crypt-problems.html) Anyway, I think you just forgot to add "allow-discards" option for your LUKS device to /etc/crypttab - see man crypttab. Then systemd will activate encrypted device with trim enabled, allowing it to use for fs/lvm/whatever on top of it.)
re-opening this, as i've run into the same problem on a machine upgraded from Fedora 17 to Fedora 18, which is a regression because it worked in Fedora 17. funny thing is if i boot into Fedora 18 using the kernel from Fedora 17 (vmlinuz-3.7.3-101.fc17.x86_64) then it _does_ work, so perhaps it's a dracut/kernel problem? [root@bastet ~]# cat /etc/crypttab luks-uuid UUID=uuid none allow-discards with kernel vmlinuz-3.7.3-101.fc17.x86_64: [root@bastet ~]# lsblk -D NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 └─sda3 0 512B 2G 0 └─luks-uuid (dm-0) 0 512B 2G 0 [root@bastet ~]# dmsetup table /dev/mapper/luks-* | grep allow_discard | wc -l 1 [root@bastet ~]# fstrim -v / /: 56932372480 bytes were trimmed with kernel vmlinuz-3.7.4-204.fc18.x86_64: [root@bastet ~]# lsblk -D NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 └─sda1 0 512B 2G 0 └─sda2 0 512B 2G 0 └─sda3 0 512B 2G 0 └─luks-uuid (dm-0) [root@bastet ~]# dmsetup table /dev/mapper/luks-* | grep allow_discard | wc -l 0 [root@bastet ~]# fstrim -v / fstrim: /: FITRIM ioctl failed: Operation not supported [root@bastet ~]# fstrim -v /boot /boot: 399737856 bytes were trimmed of course /boot is not encrypted, so what doesn't work here is clearly the device-mapper/luks stuff.
Do you have that LUKS volume specified also on kernel line? Then it is perhaps processed there before crypttab is parsed (there is some systemd bug for that I think). If I run luksOpen manually, it works as expected. Reassigning, crypttab is processed by systemd.
a "wdiff" between the grub2.cfg "linux" line that works with F17 kernel and the one that doesn't shows the only difference is the "vmlinuz". the line does reference the LUKS volume in "root=/dev/mapper/luks-" and "rd.luks.uuid=luks-" parameters. the line does not include "allow-discards root_trim=yes" parameters that i've seen on some web pages related to trim, but i've added those manually when booting the F18 kernel via the grub "edit" earlier today and it didn't make a difference (the F17 kernel is evidently fine without those options).
Same here, after a fresh install on an ssd with btrfs and encryption enabled.
This might be a dracut problem. Can you boot with "rd.break" and do in the dracut shell: # cp /etc/crypttab /run/initramfs # exit Then in the booted system attach /run/initramfs/crypttab to this bugreport, if it does not contain "allow-discards". Optionally try the dracut parameters: rd.luks.allow-discards=<luks uuid> Allow using of discards (TRIM) requests for LUKS partitions with the given UUID. Any "luks-" of the LUKS UUID is removed before comparing to <luks uuid>. The comparisons also matches, if <luks uuid> is only the beginning of the LUKS UUID, so you don’t have to specify the full UUID. This parameter can be specified multiple times. rd.luks.allow-discards Allow using of discards (TRIM) requests on all LUKS partitions.
results $ cat /run/initramfs/crypttab luks-3826a24c-90f1-4464-94fb-5f70dd5fb790 /dev/sda2 - timeout=0,allow-discards $ cat /etc/fstab # # /etc/fstab # Created by anaconda on Wed Feb 6 09:20:39 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=c8f5bc7a-be01-4ef3-a304-ac7e467d4e4e / btrfs subvol=root,discard,x-systemd.device-timeout=0 1 1 UUID=c00ed86f-288f-43d2-b812-309cd6dd4ec5 /boot ext4 defaults 1 2 UUID=c8f5bc7a-be01-4ef3-a304-ac7e467d4e4e /home btrfs subvol=home,discard,x-systemd.device-timeout=0 1 2 /dev/mapper/luks-3826a24c-90f1-4464-94fb-5f70dd5fb790 swap swap defaults,x-systemd.device-timeout=0 0 0 so this /run/initramfs/crypttab only contains information about my swap partition...
my results: in /etc/crypttab i can see /dev/sda3 _with_ allow-discards. however "exit" from the "rd.break" shell does not boot the system successfully, it hangs displaying a white square instead of Fedora logo. i tried both variants of "rd.luks.allow-discards" and neither makes any difference.
(In reply to comment #8) > my results: > i tried both variants of "rd.luks.allow-discards" > and neither makes any difference. I've been fighting with this problem recently and the only solution I've found was removing any reference in grub to the luks partition at /etc/default/gruband regenerate the with the command grub2-mkconfig > /boot/grub2/grub.cfg The problem is related in the #890533 dependency because if the luks partition is referenced in kernel it ignores the content of /etc/crypttab and the parameter luks.allow-discards=1 is currently ignored.
I can confirm that changing the kernel options in grub to remove all rd.luks.uuid=* mentions now allows me to run fstrim. [jens@ca60c173 ~]$ sudo fstrim / -v /: 14943338496 bytes were trimmed [jens@ca60c173 ~]$ sudo fstrim /home/ -v /home/: 14663667712 bytes were trimmed however, I'm not sure if they are acutally trimmed, since rerunning the command keeps on trimming a very high amount of bytes. (where this does not happen with /boot) [jens@ca60c173 ~]$ sudo fstrim /home/ -v /home/: 14683959296 bytes were trimmed [jens@ca60c173 ~]$ sudo fstrim / -v /: 14677135360 bytes were trimmed [jens@ca60c173 ~]$ sudo fstrim /boot/ -v /boot/: 354381824 bytes were trimmed [jens@ca60c173 ~]$ sudo fstrim /boot/ -v /boot/: 0 bytes were trimmed [jens@ca60c173 ~]$ sudo fstrim /boot/ -v /boot/: 0 bytes were trimmed [jens@ca60c173 ~]$ sudo fstrim / -v /: 14679379968 bytes were trimmed
I can confirm this is a regression. In F17, adding allow-discards in /etc/crypttab and rebuilding the dracut image was enough to open the the device with discards support. I've tried adding "rd.luks.uuid=luks-X rd.luks.allow-discards=luks-X" in the boot options with no luck.
removing rd.luks.uuid=* from /etc/default/grub and regenerating the grub config via grub2-mkconfig -o /boot/grub2/grub.cfg fixed the issue for me
(In reply to comment #12) > removing rd.luks.uuid=* from /etc/default/grub and regenerating the grub > config via grub2-mkconfig -o /boot/grub2/grub.cfg fixed the issue for me A side effect of this workaround seems to be that booting is slowed down. The time span from GRUB to LUKS password entry seems to be a lot longer now.
(In reply to comment #13) > (In reply to comment #12) > > removing rd.luks.uuid=* from /etc/default/grub and regenerating the grub > > config via grub2-mkconfig -o /boot/grub2/grub.cfg fixed the issue for me > > A side effect of this workaround seems to be that booting is slowed down. > The time span from GRUB to LUKS password entry seems to be a lot longer now. Another side effect is that the keyboard layout isn't configured. I don't know why, but I had to enter my passphrase with English layout.
This should be fixed in git.
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
Package systemd-201-2.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2 then log in and leave karma (feedback).
Package systemd-201-2.fc18.4: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.3 then log in and leave karma (feedback).
Package systemd-201-2.fc18.5: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5 then log in and leave karma (feedback).
I have just installed this version, and I am still seeing the same issue: $ sudo fstrim -v / fstrim: /: FITRIM ioctl failed: Operation not supported $ sudo fstrim -v /boot /boot: 354415616 bytes were trimmed
re-opening. after installing from updates-testing the packages systemd-201-2.fc18.5.x86_64 and installing a new kernel (which i assume is necessary to get the initramfs rebuilt)... everything behaves exactly the same as before, same as comment #20, even with rd.luks.allow-discards on kernel command line.
(In reply to comment #21) > re-opening. > > after installing from updates-testing the packages > systemd-201-2.fc18.5.x86_64 > > and installing a new kernel (which i assume is necessary to get the > initramfs rebuilt)... > > everything behaves exactly the same as before, same as comment #20, > even with rd.luks.allow-discards on kernel command line. can you recheck the crypttab in the initramfs image? # lsinitrd /boot/initramfs-$(uname -r).img | fgrep etc/crypttab and the contents # # lsinitrd /boot/initramfs-$(uname -r).img etc/crypttab
(In reply to comment #22) > can you recheck the crypttab in the initramfs image? > > # lsinitrd /boot/initramfs-$(uname -r).img | fgrep etc/crypttab there is apparently no such file in there.
(In reply to comment #23) > (In reply to comment #22) > > can you recheck the crypttab in the initramfs image? > > > > # lsinitrd /boot/initramfs-$(uname -r).img | fgrep etc/crypttab > > there is apparently no such file in there. I'm seeing the same thing: [root@localhost ~]# lsinitrd /boot/initramfs-$(uname -r).img | fgrep etc/crypttab [root@localhost ~]#
I was able to include /etc/crypttab in my initramfs by running "dracut -fv -I /etc/crypttab", but it doesn't appear to have any effect. dmsetup still doesn't show allow_discards, and fstrim still reports "Operation not supported".
What's the emoticon for slapping oneself on the forehead? The option that must be added to /etc/crypttab is "allow-discards" (with a *hyphen* rather than an underscore). dmsetup then shows it with an underscore. Sigh. After editing /etc/crypttab to use the proper flag and rebuilding my initramfs with "dracut -fv -I /etc/crypttab", TRIM appears to be working.
Ian, it differs because you are checking two different layers. The "allow_discards" is mapping table parameter inside kernel while dracut uses userspace cryptsetup to configure it and parameter is "--alllow-discard" so it is consistent. I would better use "cryptsetup status <device name>" than dmsetup to check if discards are enabled, you should see: flags: discards for active device.
I've upgraded to F19 and now the Luks device is open with 'allow_discards'. I have rd.luks.allow-discards=luks-XXXX in the boot cmdline in /etc/default/grub, I don't know if that is necessary.
Seems to be a dracut issue as I read the latter comments, reassigning.
On a recent F20 beta install, I was unable to enable TRIM support on a luks-backed ext4 filesystem on an SSD that works fine with TRIM with an unencrypted FS. 1. Edit /etc/crypttab, adding "discard" in place of "none" for each line that required TRIM. 2. Rebuild initramfs with dracut -vf -I /etc/crypttab 3. Reboot, test using fstrim / I also tried allow-discard and allow-discards, following the same method above. None of them allowed me to use "fstrim". Please advise if there's additional output I should include to assist figuring out what's wrong.
Rather than adding "discard" in place of none, I aded "discard" after none, and that seemed to get TRIM working, sorry for the noise.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Christopher Wawak from comment #31) > Rather than adding "discard" in place of none, I aded "discard" after none, > and that seemed to get TRIM working, sorry for the noise. Do you mean adding a fourth option of "discard"? i.e. luks-ZZZ UUID=YYY none discard
(In reply to Need Real Name from comment #33) > Do you mean adding a fourth option of "discard"? > i.e. luks-ZZZ UUID=YYY none discard Correct, so like this: luks-crypt UUID=dead-beef-beef-beef none luks,discard From man crypttab(5): The third field specifies the encryption password. [...] The fourth field, if present, is a comma-delimited list of options. Hope this helps!
Trim should really work in F20