SBC question about block coherency

Yoder, Alan agy at netapp.com
Tue Nov 15 10:30:32 PST 2011


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1111153_f.htm">HTML-formatted message</a>

> I¹m not aware of any language that requires serial command completion
Maybe not languages proper, but OS primitives  and FS interfaces do.  In
CIFS, for example, all I/O is serial unless you specify "overlapped" I/O.
And you'd use locking to control whether reads simultaneous with your writes
were allowed (default is not).	POSIX has similar controls.
My take is that any issue here is handled by higher level constructs; no
real OS is going to allow overlapping reads and writes without the explicit
permission of the programmer.
Alan
On 11/14/11 10:37 PM, "Knight, Frederick" <Frederick.Knight at netapp.com>
wrote:
> I would also add, that your statement about ³the LBA² is also correct.  If
in
> your example, these READ and WRITE commands are operating on an overlapping
> multi-LBA range, I¹m not aware of any language that requires serial command
> completion.
>  
> Obvious, as Gerry stated, restricted reordering (see SAM) does add
> requirements on WRITES, but multiple normal SIMPLE tagged commands in the
> unrestricted environment may all overlap.  If you extend your READ/WRITE
> question so that each request involves multiple LBAs, you can see that ³the
> LBA² is now significant, in that the READ (of multiple LBAs) is no longer
> guaranteed to read all old data or all new data ­ each LBA would
independently
> be old or new, such that your data-in buffer may contain some random mix of
> blocks containing old data, and blocks containing new data.
>  
> I would call it Option 3:
> There is an inherent race condition so that as  the WRITE and the READ
> commands are processed, they do atomic operations individually on each LBA
> referenced by that command, at the same time that the other command also
does
> atomic operations individually on each LBA referenced by that command.  No
> matter which command begins processing first, the data that is read may
> contain some whole blocks that contain old data and some whole blocks that
> contain new data.
>  
>		  Fred
>  
> 
> From: Gerry Houlder [mailto:gerry.houlder at seagate.com]
> Sent: Monday, November 14, 2011 4:51 PM
> To: T10 Reflector
> Subject: Re: SBC question about block coherency
>  
> Option 1 is the expected behavior. From the point of view of the SCSI
target
> device, commands are not received simultaneously; there will always be a
> mechanism that will cause one of the commands to be logged as being
received
> ahead of the other.
> 
>  
> 
> However there can be other influences on that ordering.
> 
> (a) Due to system configuration details (e.g., expanders), command might be
> sent from a host in one order but received by the target in a different
order.
> 
> (b) If all commands are SIMPLE task attribute, they may be reordered once
they
> are received into the target's queue. I would not expect commands that
access
> the same LBA to be reordered with respect to each other, but this is
allowed
> if "unrestricted reordering" is set in the Control mode page. If
"restricted
> reordering" is set in the mode page instead, then reordering of writes with
> respect to reads of the same LBA is not allowed.
> 
> (c) A command with HEAD OF QUEUE attribute is usually placed ahead of other
> commands that are in the queue. There are exceptions for commands that have
> already started processing so there is some gray area here.
> 
> On Mon, Nov 14, 2011 at 11:32 AM, Kevin D Butt <kdbutt at us.ibm.com> wrote:
> 
> I have a question that seems obvious, but since I come from the tape world
and
> have not spent much time in the disk world I could be assuming behaviors
that
> I shouldn't. 
> In the tape world, if a logical block is overwritten, then the read of that
> logical block cannot occur until after the write has been completed. The
> tape's command queue is essentially an ordered queue. In the disk world, as
I
> understand it, many commands can be processed in parallel, that is, the
queue
> is not necessarily an ordered queue. So, I have a question about what that
> parallel'ness means when the command arrives with a task type of HEAD OF
> QUEUE. 
> 
> In the example of a WRITE being issued at the same time as a READ being
issued
> for the same LBA from multiple application clients (i.e., in different task
> sets), what should be expected?
> 
> Option 1:
> There is an inherent race condition so either the WRITE or the READ command
> will arrive first and be processed as an atomic operation on the LBA, then
the
> other command will be processed on the LBA. If the READ arrives first the
data
> that is read is the old data. If the write arrives first the new data is
> written and then the read reads the new data.
> 
> Option 2:
> There is an inherent race condition so either the WRITE or the READ command
> arrives first, but both commands are processed simultaneously and the READ
> command returns data that contains partially old data and partially new
data.
> 
> Thanks,
> 
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> Data Protection & Retention
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
> 
>  
> 



More information about the T10 mailing list