sd: protection difficulties

sd: protection difficulties

[Douglas Gilbert]

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.

Re: sd: protection difficulties

[Martin K. Petersen]

>>>>> "Doug" == Douglas Gilbert <dgilbert@interlog.com> writes:

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

Re: sd: protection difficulties

[Douglas Gilbert]

On 11-11-17 12:01 PM, Martin K. Petersen wrote:
>>>>>> "Doug" == Douglas Gilbert<dgilbert@interlog.com>  writes:
>
> 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?

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
> behavior to always check PI even when the app tag contains 0xFFFF (which
> means "don't check" this block).

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

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

Hopefully this thread expedites matters.

Doug Gilbert