[PATCH v2 2/3] block: support PI at non-zero offset within metadata

Kanchan Joshi joshi.k at samsung.com
Thu Sep 26 09:38:09 PDT 2024


On 9/26/2024 8:37 PM, Keith Busch wrote:
> On Thu, Feb 01, 2024 at 06:31:25PM +0530, Kanchan Joshi wrote:
>> Block layer integrity processing assumes that protection information
>> (PI) is placed in the first bytes of each metadata block.
>>
>> Remove this limitation and include the metadata before the PI in the
>> calculation of the guard tag.
> 
> Very late reply, but I am just now discovering the consequences of this
> patch.
> 
> We have drives with this format, 64b metadata with PI at the end. With
> previous kernels, we had written data to these drives. Those kernel
> versions disabled the GUARD generation, so the metadata was written
> without it, and everything was fine.
> 
> Now we upgrade to 6.9+, and this kernel enables the GUARD check. All the
> data previously written to this drive is unreadable because the GUARD is
> invalid.
> 
> Not sure exactly what to do about this, but it is a broken kernel
> upgrade path, so wanted to throw that information out there.
> 

Ah, writing to the disk without any guard, but after that reading with 
the guard!

I wish if there was a way to format the NVMe only to reset its pi type 
(from non-zero to 0).
But there are kernel knobs too. Hope you are able to get to the same 
state (as nop profile) by clearing write_generate and read_verify:
echo 0 > /sys/block/nvme0n1/integrity/read_verify




More information about the Linux-nvme mailing list