[solved] using fstrim with encrypted filesystem

[jiml8]

The SCSI subsystem in my workstation is old and is becoming unreliable. So, I've had a migration route planned, and was prepared to implement it when next I experienced a failure.

Well, that happened Tuesday. A hard drive went down. So I ordered a new Samsung 500 GB SSD, planning to replace the failed HD and one other when the SSD arrived. So it arrived today. I shut down the workstation, plugged in the new SSD along with all the other drives, powered the system back up...and the system hard drive (also a SCSI drive) refused to start. Couldn't get it to power up. So, now, I have a double HD failure to contend with. Happy happy, joy joy.

To make it more fun, the drive that failed Tuesday contained the backup of my system, while the failure today was my system. What fun. My second backup is on my NAS, so I had to get the system from there.

To keep this short, I restored my system from the NAS copy, and now I have my system running on a new SSD. I allocated 30 GB for the system, and the rest is another partition of some 460 GB. It now contains all the contents of both the failed SCSI drives.

Now, I never encrypt my system partition, but I do encrypt everything else. So I have this second partition on my shiny new SSD that is encrypted, and that includes the bulk of the SSD.

How do I make TRIM work with this? Following what I have found on the web, I set up my crypttab to look like this:

Code: Select all

crypt_sdc5 UUID=47141196-6ce9-4119-9fca-8b8025556cae none luks,discard


Also, here is the line from fstab:

Code: Select all

LABEL=SDC5 /mnt/sdc5 ext4 relatime,nofail 0 0


But, when I run "fstrim /mnt/sdc5", I get this:

Code: Select all

fstrim: /mnt/sdc5: FITRIM ioctl failed: Operation not supported

However, "fstrim /" works fine. I therefore infer the problem is due to the encryption.

Now, I have not rebooted since doing this, though I have unmounted sdc5, closed it with cryptsetup luksClose, reopened it, and remounted it (actually, systemd promptly remounted it when I reopened it). Because this is not the root filesystem, I saw no need to use dracut to rebuild the initrd; this partition is not mounted until after the system is running.

So, can some kind soul tell me what is wrong here? I don't see a thing wrong, but something must be.

[doktor5000]

There can be multiple causes:
http://kb.sp.parallels.com/en/122080
https://bbs.archlinux.org/viewtopic.php?id=167807
https://access.redhat.com/solutions/773263
http://blog.christophersmart.com/2013/0 ... ks-on-ssd/

You don't use LVM over LUKS, no?

[jiml8]

It turns out that I do have to generate a new initrd and reboot. This was simple enough, I just didn't realize it was necessary for a non-system drive.

Anyway, the solution turns out to be (in addition to the steps described in my first post) to issue the appropriate dracut command as root:

Code: Select all

dracut -f -I /etc/crypttab

and reboot.

No, Doktor. I am not using lvm, just luks.