Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm surprised no one has mentioned that using software full disk encryption on an SSD is a really bad idea. It increases wear dramatically, completely invalidates TRIM and works against the controller every step of the way. LVM has an option that supposedly passes TRIM through but in my case I'm pretty sure it didn't do anything.


Can you explain more about this?

Even if my disk wore off faster, I'd still use full-disk encryption. What if laptop is lost or stolen with financial info in it?


Right. The thing is, when you wear out an SSD, you get these enormous (multiple seconds) pauses that, if you're doing anything I/O bound slow you down to a crawl. Even opening a heavy web page can trigger them. Buy a fast HDD if you want consistent long term behaviour with FDE.

The reason FDE breaks SSDs is that the implementation in LVM works at the block level. To send TRIM, the filesystem says "this block is empty, tell the controller" but depending on a thousand things, among which are cipher mode, cipher block size and other minutiae, LVM will invalidate the TRIM command. Without TRIM, SSDs deteriorate rather quickly.

Personally, I understand why FDE is needed but I'm of the opinion that selective encryption (with possible plausible deniability measures) is a much neater, if more difficult, approach.


You should enable encryption at the controller level, many modern SSD support it and it shouldn't influence the performance.


Indeed! Which is why I said "software full disk encryption" in my OP. :)


Also, I would want to know the difference between Full Disk Encryption of file/folder-based encryption like ecryptfs in the wear and tear on SSDs.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: