sd: protection difficulties

When a disk is freshly formatted with protection type 1 (ST33000650SS 3 TB taking 14 hours!) then its 8 bytes of protection information on all LBs are set to 0xFF.

Now with zeros filling the user data part of each logical block and a LB guard field of 0xffffffff that means any attempt to read a LB before it is written will result in an error like this [lk 3.1.0]:
sd 6:0:0:0: [sdb]
Target Data Integrity Failure
Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Sense Key : Aborted Command [current] Add. Sense: Logical block guard check failed
CDB: Read(10): 28 20 00 00 00 00 00 00 08 00
end_request: I/O error, dev sdb, sector 0

That is gparted reading LBA 0 to find out what partition table the disk has. Answer: no partition table because that LB has not been written to (since the FORMAT UNIT).

Since the block layer insists on reading a disk before writing, and that the sd driver is setting the RDPROTECT field to 1 *** (i.e. the 0x20 is the second byte of the CDB above), then no tool that uses the block layer interface (i.e. /dev/sdb) can work with that disk. That includes dd.

The only way I can see to make that disk useable currently is with a generic pass-through (e.g. the bsg or sg drivers) and write to the disk. My sg_dd and ddpt utilities can do that. Just writing zeros (with correct protection information) to the beginning and end of the disk to keep GPT stuff happy is not sufficient. That implies mkfs-type programs are also doing read-before-write. So lets waste another 14 hours writing zeros (with correct protection information) to the whole disk.

Seems to be getting a bit silly. Am I missing something obvious or does the sd driver and the block layer above it need some serious work?

How about starting with the idea of a "tentative read". That is a read operation to a LBA that it is not reasonable to assume has always been written to. The first read to a disk should always be tentative because the disk could have just been formatted (BTW the WRITE SAME command can also place 0xFF bytes in the protection fields).

Doug Gilbert

*** Recent work at t10.org states that if RDPROTECT=0 on
a READ command and the DPICZ bit is 1 in the Control mode page then the protection information shall _not_ be checked. The ST33000650SS disk does not support the DPICZ bit and when RDPROTECT=0 it does not check protection information. Reports about other disks on the market that support protection information welcome.

Doug,

Doug> Now with zeros filling the user data part of each logical block Doug> and a LB guard field of 0xffffffff that means any attempt to read Doug> a LB before it is written will result in an error like this [lk Doug> 3.1.0]:
Doug> sd 6:0:0:0: [sdb]
Doug> Target Data Integrity Failure

Doug>     Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Sense Key :
Doug>     Aborted Command [current] Add. Sense: Logical block guard
Doug>     check failed CDB: Read(10): 28 20 00 00 00 00 00 00 08 00
Doug>     end_request: I/O error, dev sdb, sector 0

I'm guessing you are using an mpt2sas with recent firmware? LSI changed behavior to always check PI even when the app tag contains 0xFFFF (which means "don't check" this block).

I have some patches that LSI haven't signed off on yet. Which is why I haven't posted them...

Martin K. Petersen	Oracle Linux Engineering

Yes:
mpt2sas version 09.100.00.00 loaded

Whenever I report a bug to LSI (who are much better than most) they always say to upgrade to the latest firmware and re-test :-)

LSI changed

That useful piece of information is well hidden! [sbc3r29.pdf section 4.21.3 top of page 61] You learn something every day.

Hopefully this thread expedites matters.

Doug Gilbert