Want to make sure I'm handling my SSD properly

Message

mikegpitt · Post by **mikegpitt** » Fri Aug 12, 2016 7:43 pm

I want to make sure I configure my SSD properly in my new laptop. For my last laptop I set the discard option for / and left it at that. I've read though that this currently isn't the best way to handle things.

My new machine has an NVME type SSD drive. I have all of Gentoo inside a LUKS partition, and inside the LUKS partition I have three LVM partitions (/, /boot, and swap).

What's the proper way to handle SSD discards, so my drive stays in good shape?

Do I add the 'root_trim=yes' option to GRUB_CMDLINE_LINUX_DEFAULT? Do I add 'issue_discards = 1' to /etc/lvm/lvm.conf? Should I do both?

Do I run 'fstrim -v /' in a cron regularly? From the documentation, it seems like I would not need to because of LVM, but I'm not 100% sure.

There's also opening cryptsetup with --allow-discards. I'm unsure if this is something else I would want to do. The LUKS drive is mounted by grub2 to load the initramfs and then during boot, so if I do need to add --allow-discards, this option would need to be added to some config... or maybe it's applied automatically by the root_trim=yes kernel option? I've also read that --allow-discards reduces the security of the encrypted drive, so maybe it's not a good thing to enable.

Lot's of options here. Just want to make sure I'm doing things in a proper way so I get good life out of my drive.

Post by **NeddySeagoon** » Fri Aug 12, 2016 8:01 pm

mikegpitt,

LUKS and trim are not compatible.

A LUKS volume should look like random data at all times. Even when the filesystem is empty, hence at create time you fill it with (psudo)random data.
Trim instructs the SSD to erase data blocks, ready for writing, removing the random data that was there.

LUKS still encrypts the data that is present on the drive but its now easy for an attacker to see where that data is stored, which is an aid to the attacker.

What threat is your use of LUKS defending against?

mikegpitt · Post by **mikegpitt** » Fri Aug 12, 2016 8:16 pm

NeddySeagoon wrote:LUKS and trim are not compatible.

OK, this is in line with what I've read. So, should trim be enabled for the LVM partitions inside of LUKS, or is this out as well? And, if I don't enable trim at all, does this reduce the life or performance of my SSD over time?

NeddySeagoon wrote:What threat is your use of LUKS defending against?

I have business data on my machine that I'm obligated to secure, as well as personal data that I want to keep secure. Basically the use case is, if my machine is ever lost of stolen the data remains locked forever. I'd like to mitigate targeted threats as well, but guarding against highly sophisticated targeted threats isn't a likely scenario for me. If that happens, they can have my photo and MP3 backups.

I'm mainly concerned about the health of the drive over time. Catastrophic drive failure would be the scenario I most want to avoid, even though I keep regular backups.

Post by **NeddySeagoon** » Fri Aug 12, 2016 8:47 pm

mikegpitt,

When you trim an SSD, the physical blocks are erased on the SSD. This prepares it for future writes.
Not using trim makes an attack harder as data areas on the filesystem cannot be identified but there is a write speed penalty, since for every write, you must wait the erase time.

You may not notice this in everyday use, since a standard LUKS install has the drive filled with random data anyway and you already incur the erase penalty.
Its most noticable to the user when the drive is fast from new but with trim not in use, the write speed falls when the drive begins to reuse previously written but net erased blocks.
Its the sudden change in write speed that users notice.

SSD life is reduced without trim as 'write amplification', is maximised. This in due to the erase block size being much larger that the write block size, e.g. an erase block may be 64 or more write blocks.

mikegpitt · Post by **mikegpitt** » Fri Aug 12, 2016 9:54 pm

NeddySeagoon wrote:SSD life is reduced without trim as 'write amplification', is maximised. This in due to the erase block size being much larger that the write block size, e.g. an erase block may be 64 or more write blocks.

This is what must have happened to my previous drive. Over the last year things kept getting slower and slower... especially if I was importing a several GB mysqldump. And that was with discard turned on.

So, it sounds like that I have two options:
1) Do nothing and wait for the disk to slow down... and I guess eventually wipe the disk and re-install.
2) Enable --allow-discards for LUKS, which will decrease drive security, but possibly keep the drive writing speed better over time.

I have to say that #1 doesn't sound very good. #2 isn't great either, but it might get into the 'sophisticated targeted' attack area which I'm not really concerned about. I may got the #2 route, as I really don't want to trash my machine in a year or two.

If anyone knows of a good #3 option, I'd like to hear it!

Thanks @NeddySeagoon for your input! Your feedback helped me narrow down the options I'm looking at. If I understand correctly: Using discard at the LVM level is not necessary, because it sits on top of LUKS. And fstrim will also not help or be what I need in this situation, as the file system sits on top of LVM. So, my choices are to LUKS discard or not.

frostschutz · Post by **frostschutz** » Sat Aug 13, 2016 1:47 pm

I described my take on SE here http://unix.stackexchange.com/a/218083/30851 and here http://unix.stackexchange.com/a/80868/30851

I only run fstrim once a month since that's enough for me.

Regarding LUKS --allow-discards and drive security: It's a whole lot of nonsense. Where is security decreased? All data is encrypted. Yes, you can see how much freespace/data there is and where. But what can you do with it?

This is completely normal e.g. for filesystem based encryption (ecryptfs, encfs, ext4 builtin encryption, ...), it doesn't mean it's insecure. Also you should consider security as a whole: Is your setup resilient against keyloggers, backdoors, XKCD decryption wrench ...?

Most setups have glaring weakpoints elsewhere so this very theoretical attack due to revelation of free space matters very little.

Regarding LVM issue_discards, you really want to stick to 0 here. Otherwise you can not revert a botched lvresize, since LVM will happily instantly discard all your data.

If you want to discard all free space in LVM, you can `lvcreate -l100%FREE -n deleteme vg; blkdiscard /dev/vg/deleteme; lvremove vg/deleteme`.

Most TRIM data loss bugs were related to NCQ / Queued Trim. I don't fully trust this system so I have disabled NCQ ( `libata.force=noncq` ). For me this also improved HDD performance, it seems my WD Green HDDs do not handle NCQ very well either.

Akkara · Post by **Akkara** » Sat Aug 13, 2016 10:46 pm

mikegpitt wrote:If anyone knows of a good #3 option, I'd like to hear it!

Use LUKS normally, don't bother with trim/discards. After "a while" - like if it starts to slow down - copy the whole thing over to another drive, verify it thoroughly, then do a full clear on the first one. If your second drive is also a SSD and set up with LUKS, swap them in your machine and save the first one for the next round of this. If you don't want to swap drives or it wouldn't be advantageous to do so, copy it all back, verify again, and perhaps keep that 2nd drive as a full backup.

You might also find that "after a while" never comes, that it keeps being fast enough. Which is a fine answer as well.

Post by **NeddySeagoon** » Sun Aug 14, 2016 9:41 am

mikegpitt,

It all depends on the drive firmware ...
A modern SSD contains two block pools. Those blocks that are mapped into the the drives users space (blocks visible to the user), and those blocks that are not.

The two block pools are not essential for wear levelling and on old drives, like my 8G SSD from 2008, the second pool will be missing.
With a standard LUKS setup, just installed, the user space is completely written and the other blocks are completely erased.

At your first write, the drive can (depending on the firmware) read the erase block it needs to modify, swap it for a pre erased block from the blocks not allocated to userspace, then do your write to the clean block. That way, you don't see any erase penalty.

In the background, the drive can erase block it swapped out that contains your old data, so its clean for another write.

SSD firmware is a trade secret. You may never hit the erase delay.
The above does not require the use of trim/discard, just the extra layer of indirection that all modern SSDs contain.

mikegpitt · Post by **mikegpitt** » Wed Aug 17, 2016 3:43 pm

Thank you everyone for the feedback... my apologies for ignoring the thread for a few days. I did read everything a couple days ago.

I generally agree with @frostschutz, and put this type of attack in the highly sophisticated and targeted range. But, from what everyone else is saying, it sounds like there may be minimal impact if any if I did allow the discards -- since all of userspace is already filled -- and I should just deal with the disk slowdown when it happens, if it happens.

My last machine's SSD slowed down an extreme amount, and that was with discards. Based on what Neddy said, I'm guessing this is because I started to run out of the second block pool. I had the laptop for three years though, and since I only have 4GB of memory, I was not able to compile some big packages (chrome, firefox, libreoffice) in memory. I'm sure that increased the drive wear. My new machine has 16GB of RAM, so I can do all portage related work in memory, which should help out a lot... and since it's 16GB it also means I'll be swapping less often again reducing drive wear. My last SSD was only 128GB, and I was hitting 90% utilization, which I have heard is bad for SSD's. My new drive is 512GB, which is more than enough space for me... of course maybe that doesn't really matter because I'm using 100% with LUKS.

SSD's are great, but they are sort of a pain to deal with.