Re: [PATCH 07/14] target/sbc: Add P_TYPE + PROT_EN bits to READ_CAPACITY_16

[Douglas Gilbert <dgilbert@interlog.com>]

On 14-01-12 12:21 PM, Martin K. Petersen wrote:
>>>>>> "Doug" == Douglas Gilbert <dgilbert@interlog.com> writes:
>
>>> So this takes me to a corner I still don't understand, if a LUN is
>>> pre-formatted as T10-protected, what happens to unwritten blocks
>>> read?  I mean, SCSI login executes some reads from sevel LBAs which
>>> will probably fail as blocks are unwritten.
>
> Doug> Some observations: I haven't seen any disks pre-formatted with
> Doug> T10-protection, they usually come pre-formatted without
> Doug> T10-protection.
>
> Depends where you buy them. All the drives we ship arrive formatted with
> T10 PI from the manufacturer.
>
> However, nobody expects you to format a LUN on an array. When you create
> a LUN on a PI-capable storage array, T10 PI is a storage management
> interface option just like size, RAID level, etc. Upon creation, arrays
> zero out newly provisioned LUN blocks and write parity, etc. If PI is
> enabled on a LUN, blocks are written with all zeroes in the data block
> and all ones in the trailing PI tuple. This is all part of the regular
> LUN setup procedure.
>
> In any case. The usage model is that you never format a disk unless you
> are a tinkerer and bought a retail SAS drive at Fry's. Drives will be
> delivered by your server vendor formatted with PI and ready to go.

Only tinkerers would contribute to something like
the scsi_debug driver. After all, the pros could
rely on their T10 compliant vendor equipment :-)

And you are right, I do like to test sg_format
against something real. Perhaps sg_format is the
utility those server vendors use. Another
tinkerer called James Bottomley wrote the original
sg_format code, according to my notes.

> If you use a non-disk storage device, whether or not to enable PI is
> part of the LUN provisioning procedure (array management console, RAID
> or flash controller card config utility, etc.)
>
> Doug> So a tentative READ, for example checking if a disk has a
> Doug> partition table, could be preceded by a GET LBA STATUS
> Doug> command. IMO, if provisioning is enabled, LBPRZ=0 then the GET LBA
> Doug> STATUS command should be mandatory.  Otherwise a tentative READ is
> Doug> a lucky dip.
>
> It's perfectly valid to do a legacy/unprotected READ from a T10 PI
> device. Doesn't matter whether the blocks are unwritten or not.

Ah, the current SBC-3 draft (sbc3r36.pdf) does say if one
does a READ from a disk with logical provisioning enabled
and LBPRZ=0 then the block data is "vendor specific" and
the PI, if any, is all 0xff bytes. That last bit was added
in sbc3r34.pdf (and it was "any value" prior to that).

Back to the original question, I don't think Sagi was
asking if it was valid to do a legacy/unprotected READ,
it was what to expect with a protected READ on
unwritten blocks:

 > So this takes me to a corner I still don't understand, if
 > a LUN is pre-formatted as T10-protected, what happens to
 > unwritten blocks read?

So the precise answer is: the PI will be all 0xff bytes,
unless logical provisioning is enabled, LBPRZ=0 and the
device's compliance predates sbc3r34.pdf (November 2012).

Doug Gilbert