SBC question about block coherency

Yoder, Alan agy at netapp.com
Tue Nov 15 18:42:43 PST 2011


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

> my statement was about  ³any language² in the SCSI family of standards.
Guess my programming languages slip is showing.  ;-)
Alan
On 11/15/11 5:52 PM, "Knight, Frederick" <Frederick.Knight at netapp.com>
wrote:
> Since the original question was about raw SCSI commands and various task
> attributes associated with them, my statement was about  ³any language² in
the
> SCSI family of standards.
>  
> You are absolutely, this kind of synchronization is the responsibility of
the
> APPLICATION LAYER (where application is defined as anything above the H/W
and
> its driver ­ such as file systems, volume managers, etc, etc). At the
lowest
> level, the protocol only does what you tell it to do (and the protocol is
> perfectly happy to do overlapping reads/writes at the same time if you tell
it
> to).
>  
>		  Fred
>  
> 
> From: Yoder, Alan
> Sent: Tuesday, November 15, 2011 1:31 PM
> To: Knight, Frederick; Kevin D Butt; T10 Reflector
> Subject: Re: SBC question about block coherency
>  
>> > 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