nvme-format: protection information enabled although metadata size is 0

[Keith Busch]

On Wed, Nov 02, 2022 at 04:42:21PM +0100, Binarus wrote:
> On 02.11.2022 16:34, Keith Busch wrote:
> > On Mon, Oct 31, 2022 at 10:27:34AM +0100, Binarus wrote:
> > > On a machine with Debian Bullseye and nvme-cli 1.12, I have formatted an
> > > Intel DC P3700 the following way:
> > > 
> > >    nvme format /dev/nvme0 -l 3 -i 1 -f
> > 
> > You correctly surmised that the device is behaving out-of-compliance
> > with the specification. The device should have returned an "Invalid
> > Format" error since, as you found, this is the error to return when
> > "enabling protection information when there are not sufficient metadata
> > resources".
> > 
> > You're unlikely to find a fix for this EOL device, though. It's just a
> > firmware bug that you should avoid.
> 
> Thank you very much for confirming that this is a bug. May I steal your time again and ask what you would do in that situation? Throw away the device because we can't trust it, or format it with 8 bytes of metadata and hope that the PI works correctly then?

I think that's going too far. To the best of my knowledge, the device
works fine. You just hit an untested parameter combo. The device may
report you requested PI, but without metadata, it's going to behave the
same as a non-PI 4k format. If you supply valid paramters for pi
formats, then the device will correctly honor that.

I'm not sure if you're familiar with the different nvme metadata types
though, so I'll add that this particular model's does not work with the
Linux kernel's end-to-end protection. This device supports only the
"extended" metadata, not the "separate" that the Linux block stack
requires. You won't be able to use the generic block layer for IO with
protection information, but you should be able to use it in passthrough
modes. And if you are using the 8-byte format (LBAF 4, I believe), then
the driver will have the device strip/generate PI without the host ever
seeing it.