E2EDP in nvme fw or luks and/or fs bit-rot prevention?

Ask Fedora
1

Continuing the discussion from BTRFS as default filesystem was a bad idea:

NVMe Readiness - Part Three

XFS - Atomic File Content Commit in Linux 6.13

inline hardware metadata space

fio e2edp article

nvme id-ns -H /dev/nvme1n1

IIUC for data-at-rest ie: in the TLC/QLD flash chips, self encryption protects data integrity. If a bit rots it will cause the decryption to fail and the devices always encrypt the data even when no passphrase is set.

For data-in-flight the nvme device has a built-in ARM Cortex R8 CPU and when the flash chips are accessed and the self encryption is decrypted it lands in the device’s SRAM ECC protected. When the transfer to the host occurs PCIe transfers are protected with ECC. Commands from the host also benefit from ECC.

As far as flash cell management goes, being nvme 2.0 indicates proper management with appropriate techniques such as wear leveling or other endurance features.

With the use of Flexible Data Placement (FDP) there is a constant write applification of 1 as well.

It seems there is benefit to these features without it but host software can receive additional benefits when applications are writted to leverage these features.

Support for all this is already in the kernel since 5.19.

Now to learn nvme-cli better to discover which features an nvme device on-hand implements. Also check into what Fedora has going for it in leveraging these features. Also more DIF/DIX understanding is desired.

My understanding may not be fully correct but overall, data is well protected with these newer devices. If using a filesystem with data block checksumming, turn it off as it is redundant and reduces performance.

There were some relatively recent updates that allow for dm-integrity and T10-PI hardware to be used in powerful ways.

dm-integrity under dm-crypt enables authenticated encryption

Pretty cool. Add dm-raid and it becomes self-healing.

All at the device block level so many options open up.

With the capabilities in fio it should be possible to explore and test well. Just need appropriate hardware before the fun begins.

It looks like filesystems can leverage this integrity metadata.

2

The NVMe Readiness - Part Three document claims about half the vendors implement end-to-end data protection cir. 2018. Is there a way to display whether a storage device in use, say nvme0n1, has it?

Look into secure erasure. The Arch project has good docs on it. Basically, all the SSDs today do AES encryption at the hardware level at all times to implement secure erasure. That’s why it only takes a few seconds. It’s just a process of nuking the key stored in the firmware flash.

As for other encryption topic, There’s Opal standard. It’s not getting much attention as the vendors themselves are not that interested. So, Linux support is not there yet either.

Forget about all the bitrot the other guys are talking about. Modern hardware puts CRC all over the place it just can’t happen. There are some niches and sure, it should be done at the software level. Literally all modern filesystems are configured to do stringent checksums.

3

Any m.2 NVMe SSD meeting the NVMe 2.0 standard will include end to end ECC. One built using Silicon Graphics SM2508 such as the Kington Fury Renegade G5 is one example.

SM2508

Kingston FURY Renegade G5 SSD Review: Balanced Gen5 Performance