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
