Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Binarus <lists@binarus.de>
To: linux-nvme@lists.infradead.org
Subject: nvme-format: protection information enabled although metadata size is 0
Date: Mon, 31 Oct 2022 10:27:34 +0100	[thread overview]
Message-ID: <b9ca7931-0384-d0e1-92b5-c2ffbadc195f@binarus.de> (raw)

Dear all,

after having read the subjects of the posts in October, I am afraid that 
a dumb newbie question like the following may be inappropriate here. But 
due to the lack of other options (tried other Q & A sites without 
success), I'll be brave ... Having said this:

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

That command has been executed within a few seconds without any error. 
But in my understanding, it should have failed. '-l 3' means 4096 bytes 
LBA without metadata, but '-i 1' enables T10 protection information 
which needs 8 bytes of metadata.

Afterwards, I have checked the output of

   nvme id-ns /dev/nvme0n1 -H

It is quite long, so I am shortening it; the relevant lines are

   dps     : 0x1
     [3:3] : 0     Protection Information is Transferred as Last 8 Bytes 
of Metadata
     [2:0] : 0x1   Protection Information Type 1 Enabled
   ...
   LBA Format  3 : Metadata Size: 0   bytes - Data Size: 4096 bytes - 
Relative Performance: 0 Best (in use)

As expected, and according to the format command, a metadata size of 0 
is in use, but the protection information is enabled.

Could somebody please explain that in simple words? How can the PI be 
enabled although there is no room for the checksums, and how does the 
device actually behave now?

Best regards, and thank you very much in advance,

Binarus

P.S. From the revision 2c of the NVMe base specification, page 172, I 
also got the impression that the format command shown above should have 
failed. In figure 190, in the first table row, there is:

Invalid Format: The format specified is invalid. This may be due to 
various conditions, including:
1. specifying an invalid User Data Format number;
2. enabling protection information when there are not sufficient 
metadata resources; or
3. the specified format is not available in the current configuration.

Item 2 reflects the situation described above, doesn't it? But then the 
format command should return an error, and actually should not format 
the device, correct?


             reply	other threads:[~2022-10-31  9:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31  9:27 Binarus [this message]
2022-11-02 15:34 ` nvme-format: protection information enabled although metadata size is 0 Keith Busch
2022-11-02 15:42   ` Binarus
2022-11-02 15:59     ` Keith Busch
2022-11-02 19:32       ` Binarus
2022-11-02 19:47         ` Keith Busch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b9ca7931-0384-d0e1-92b5-c2ffbadc195f@binarus.de \
    --to=lists@binarus.de \
    --cc=linux-nvme@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox