fstrim on Samsung 850 EVO SSD (LUKS over LVM)

The-Q · 2015-10-21 17:43:12

Hey all,

I've bought a Samsung 850 EVO SSD, only to find out it has some of its TRIM commands blacklisted in libata-core.c.
AFAIK, only queued TRIM is blacklisted while periodic TRIM via fstrim is available.
Running fstrim on / which is xfs over LUKS over LVM seem to not work.

Problem is: (after reboot)
Seems like a successful to TRIM /boot (ext4, no LUKS, no LVM)

$ sudo fstrim -v /boot/
/boot: 213.2 MiB (223586304 bytes) trimmed
$ sudo fstrim -v /boot/
/boot: 0 B (0 bytes) trimmed

However when trying to TRIM /: (xfs over LUKS over LVM)

$ sudo fstrim -v /
/: 214.4 GiB (230248239104 bytes) trimmed
$ sudo fstrim -v /
/: 214.4 GiB (230248239104 bytes) trimmed

(subsequent calls might be with a slightly more bytes, up to around 100,000)

My configuration: (I verified that the initrd has the same lvm.conf as in /etc)

$ lsblk
sdc                       8:32   0 232.9G  0 disk
├─sdc1                    8:33   0   286M  0 part  /boot
└─sdc2                    8:34   0 232.6G  0 part
  └─croot               254:0    0 232.6G  0 crypt
    └─ssd_storage-lroot 254:1    0 232.6G  0 lvm   /

/etc/default/grub
GRUB_CMDLINE_LINUX="cryptdevice=/dev/disk/by-uuid/<disk's UUID>:croot:allow-discards root=/dev/mapper/ssd_storage-lroot"

/etc/lvm/lvm.conf
...
device {
...
    issue_discards = 1
}
...

$ sudo hdparm -I /dev/sdc | grep -i trim
           *    Data Set Management TRIM supported (limit 8 blocks)

Any idea? Seems like either LUKS or LVM is not forwarding the TRIM, but both configurations state it should.

(Note: I'm aware of the security implications of TRIM on LUKS)

R00KIE · 2015-10-21 20:41:07

I can't test right now because I've stopped using luks and started using my ssd to handle the encryption(1) but what I can say is that ext4 on lvm over luks does forward the discards just fine(2) _but_ you need to pass the allow-discards option in your kernel line _and_ you need to change the issue_discards option in lvm.conf so lvm forwards the discards over to luks which will forward them to the disk.

Ext4 over lvm does this here:
# fstrim -v /boot
/boot: 127.1 MiB (133251072 bytes) trimmed

# fstrim -v /boot
/boot: 0 B (0 bytes) trimmed

Mind you that if you reboot and try this again it will say it trimmed 127MiB again.

(1) I've started testing/using the locking features of my opal 2.0 compliant ssd, it does alleviate the cpu load a lot because the cpu in the machine I use does not have aes-ni instructions.
(2) I know because periodically I do full disk images (sparse images) and the space used by the image matches the space used by the filesystem.

Edit:
You seem to have all the options in place, the only other thing I can think of is: did you recreate your initramfs after you changed the lvm.conf issue_discards option? The lvm.conf file is included in the initramfs and if that has issue_discards = 0 I suppose things might not work.

Last edited by R00KIE (2015-10-21 20:47:45)

The-Q · 2015-10-21 20:49:33

As said above: "I verified that the initrd has the same lvm.conf as in /etc"

frostschutz · 2015-10-21 21:20:02

So what's the problem?

Do you expect fstrim to say 0 bytes? This is the decision of the filesystem. XFS always trims the entire free space.

AFAIK, only queued TRIM is blacklisted while periodic TRIM via fstrim is available.

This has nothing whatsoever to do with fstrim vs. discard flag. TRIM is available or it isn't. TRIM may be queued or not. Either way, you can use trim (any flavour of it) or you can not use it.

There is no kind of trim that only works with fstrim but not the filesystem's discard mount option or vice versa. [Excepting filesystems that only support one way but not the other, but that's unrelated to hardware or blacklists.]

I disable NCQ on all my systems, too many bugs in that and too little (sometimes negative) performance improvements.

Last edited by frostschutz (2015-10-21 21:30:16)

Soukyuu · 2015-12-05 15:59:14

I know this thread is old-ish, but just to chime in: I have a crucial m4 and running fstrim on / also states the same amount of space trimmed if I run it twice back to back. So it doesn't seem to be related to the samsung being blacklisted from queued trim.
The interesting thing is that further below in libata-core.c, all crucial and samsung drives are WHITElisted as returning zeroes after TRIM...

I'm running on btrfs btw, so it might be related to the FS used instead.

Arch Linux

#1 2015-10-21 17:43:12

fstrim on Samsung 850 EVO SSD (LUKS over LVM)

#2 2015-10-21 20:41:07

Re: fstrim on Samsung 850 EVO SSD (LUKS over LVM)

#3 2015-10-21 20:49:33

Re: fstrim on Samsung 850 EVO SSD (LUKS over LVM)

#4 2015-10-21 21:20:02

Re: fstrim on Samsung 850 EVO SSD (LUKS over LVM)

#5 2015-12-05 15:59:14

Re: fstrim on Samsung 850 EVO SSD (LUKS over LVM)

Board footer