Hacker News Reader

Comment by ggm | Hacker News Reader

+ Avoid SATA SSDs.

Cries into his soup, having built the home ZFS filestore out of the cheap Patriot M210 2TB SATA SSDs...

However I don't drive 'em over USB. They're on a 5 port PCIx4 SATA card.

I was surprised how hot these babies report themselves to be. I bought a myth that I would be fanless. Well, with a noctua 40mm to cool them I can't hear the fan although I have old ears. I'm mostly fanless I guess.

The amount of cache amazed me. I guess at the point your job is to write complex encoded block states, lots of RAM on the local device (for the FPGA or chipset doing the smarts, which I assume is itself a computer) doing this marshalling makes sense.

Its funny how "bad" we are as an industry, making rational choices. Like WHY do NVME SSD not implement TRIM? What is it about them that "TRIM" didn't make sense?

View on HN

> Its funny how "bad" we are as an industry, making rational choices. Like WHY do NVME SSD not implement TRIM? What is it about them that "TRIM" didn't make sense?

Maybe CrystalDiskInfo is simplifying things (combining TRIM and the mentioned DEALLOCATE command?), but all my NVMe SSDs support TRIM according to it. And it would be really strange if NVMe didn't support any sort of trimming, as SSD performance and health heavily relies on it.

It could also be that what the author is observing is specific to macOS?

The controllers on many USB SATA adapters don’t support TRIM.

That I'm aware of, but the claim is that TRIM does not exist for NVMe drives.

RE: TRIM vs DEALLOCATE, that seems to be a naming thing. Wikipedia confirms that it's indeed technically DEALLOCATE on nvme.

https://en.wikipedia.org/wiki/Trim_(computing)#NVM_Express

All of my NVME SSD's support TRIM until I encrypt them and that's by design. Are you by chance using dm-crypt on your SSD's?

>All of my NVME SSD's support TRIM until I encrypt them and that's by design

Why is this "by design"? There's no reason why disk encryption can't be compatible with trim. Yes, there's a small metadata leak, but that's fine in the overwhelming majority of cases.

This [1] is the answer and I have no control over it. It works on LUKS2 but not dm-crypt plain which I use for external backups as it is headerless and does not expose cipher and hash or that there is explicitly encrypted data despite the fact one can infer. There was talk of removing the restriction and maybe everything I said is no longer correct by now. I have not tested it in a while. The discussion was around adding the option 'cryptsetup --allow-discards' for dm-crypt plain instead of just LUKS2.

[1] - https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discar...

Reply on news.ycombinator.com