Hacker News Reader

Comment by ChrisLomont | Hacker News Reader

SSDs could still do it for speed and to write less pages, making the drive last longer, and simply report the uncompressed space as used. They already do all sorts of tricks on pages such as moving them logically, having more internally than they report to use as pages wear out, and so on.

Given that, it's good sense to compress if at all possible simply to make the drive live longer.

And guess what - I just googled, tons of hits, and this has been done for a long time :)

So it makes sense, is done, and is important for modern SSD behavior.

View on HN

None of this works if the data is encrypted.

I'm surprised (and shocked) that letting unencrypted data hit the disk is still common enough to make such optimizations worth it.

Even if you just stick the key in the server's TPM without any sealing, an encrypted disk makes it much easier to deal with e.g. drive returns (for warranty or fault analysis) or disposal.

Plenty of SSDs implement strong encryption, and there's an entire standard API for it. Why waste cpu on tasks your hardware already does?

Bitlocker supports on drive hardware encryption, and I'd be surprised if other major file systems didn't.

If I recall, it's a FIPS requirement for data at rest now.

> Why waste cpu on tasks your hardware already does?

Because the storage hardware might be loyal to someone who is not the owner of the data.

> Why waste cpu on tasks your hardware already does?

Because the hardware cannot be trusted to do it correctly. IIRC Bitlocker stopped relying on it for this reason.

https://www.howtogeek.com/fyi/you-cant-trust-bitlocker-to-en... (see the updates)

> I'm surprised (and shocked) that letting unencrypted data hit the disk is still common enough

There's very, very little benefit in encrypting data at a filesystem level in a datacenter if you think about it.

Unfortunately that's going to really depend. For example, if your threat model is "hard drive gets stolen" there's no point. If your threat model is "attacker can access my database" encrypting the data at the DB level does make sense. But it obviously breaks compression.

And unfortunately compression and encryption are seemingly at odds fundamentally :c

I explained why I think it does provide a benefit even in a datacenter:

"Even if you just stick the key in the server's TPM without any sealing, an encrypted disk makes it much easier to deal with e.g. drive returns (for warranty or fault analysis) or disposal."

Would you resell usable drives that you no longer want to use (e.g. because they're too small or your needs changed more towards SSDs) if unencrypted data was written to them at some point?

How much effort would you put into making sure that no broken drive that can't be wiped leaves the datacenter without shredding?

Any process you put in place will have gaps - e.g. through human error or malicious acts - and this provides pretty solid protection against that.

Reply on news.ycombinator.com