Re: [RFC 0/3] Btrfs checksum offload

["Martin K. Petersen" <martin.petersen@oracle.com>]

Christoph,

> Well, what do we actually need the app tag escape for except for
> historical precedence?  In NVMe the app tag escape is an option for
> deallocated blocks, but it's only one of the options, there other beeing
> a synthetic guard/ref tag with the expected value.

I have been told that some arrays use it to disable PI when writing the
RAID parity blocks. I guess that makes sense if the array firmware is
mixing data and parity blocks in a single write operation. For my test
tool I just use WRPROTECT=3 to disable checking when writing "bad" PI.

And obviously the original reason for the initialization pattern escape
made sense on a disk drive that had no FTL to track whether a block was
in a written state or not. But I really don't think any of this is
useful in a modern SSD or even array context.

>> In general I think 4096+16 is a reasonable format going forward. With
>> either CRC32C or CRC64 plus full LBA as ref tag.
>
> That would also work fine.  NVMe supports 4byte crc32c + 2 byte app tag +
> 12 byte guard tag / storage tag and 8-byte crc64 + 2 byte app tag + 6
> byte guard / storage tag, although Linux only supports the latter so far.

Yep, the CRC32C variant should be easy to wire up. I've thought about
the storage tag but haven't really come up with a good use case. It's
essentially the same situation as with the app tag.

-- 
Martin K. Petersen	Oracle Linux Engineering