SEQUENTIAL WRITE PROBLEM

[Tom Wicklund]

* From the SCSI Reflector, posted by:
* wicklund at Intellistor.COM (Tom Wicklund)
*
GFRAZIER at AUSVM6.VNET.IBM.COM writes:
 > * From the SCSI Reflector, posted by:
 > * GFRAZIER at AUSVM6.VNET.IBM.COM
 > *
 > PROBLEM
 > Many existing applications put time stamps on each end of log records so
 > thay they may recover after a system crash during the log write. If the
 > timestamps at each end of the log record are equal during recovery, then
 > they treat the record as valid.
 > Note that this behavior depends on the sectors being written to the disk
 > media in order. If a drive happens to write the last half of the data
 > before the first half (for latency minimization), then both beginning and
 > ending stamps can be correct while the center data has not been written.
 > This obviously results in an invalid log being recovered on restart.
 > 
 > SOLUTIONS
 > SSA has addressed this problem by adding a bit in it's frame header to
 > require sequential writes to the media, but unfortunately it cannot be used
 > for FCP or parallel SCSI. In order to provide a common method for all
 > physical media, a very slight revision to the EMDP bit in the
 > Disconnect/Reconnect mode page could be used.
 > The only modification would be to make the following change to the wording
 > of the EDMP bit definition: (Please see SPC, rev 8, p.101)
 > 
 >      "If the EMDP bit is zero, the target shall not reorder the SCSI data
 >       transfer OR THE DATA TRANSFER TO THE MEDIA."
 >           (Capitals indicate the change.)
 > 
 > Of course many other possible solutions to the problem exist, but I do not
 > believe this would be incompatible with existing SCSI devices, and it
 > results in the minimum impact to the standard.

I'm not fond of this solution.  Most SCSI devices don't support EMDP
but may be able to write data out-of-order once the data is all in the
drive's buffer.  This probably also makes any drive which currently
does out-of-order writes violate the standard if it doesn't happen to
set the EMDP bit.

Instead, I'd use the Queue Algorithm Modifier field in the Control
Mode page.  If the Queue Algorithm is "Restricted reordering" then
disable reordering the datya transfer to the media.  If the Queue
ALgorithm is "Unrestricted reordering allowed" then transfer to the
media can be done out of order.  This field already controls transfer
to the media, essentially controlling sorting of writes to a disk.
The applications I'm aware of which care about the transfer order of a
single write also disable sorting writes, making this setting
consistent.

If overloading this field is a problem, I prefer a new bit in the
Control Mode page to specify out of order transfer to the media.  I
think the Control Mode page is the proper place, and I think there are
a few free bits left in bytes 2..4.  Defining a new bit "In Order
Transfer to Media" (so a 1 forces in order transfer) shouldn't break
any existing devices since a 0 can be returned for both devices which
transfer in-order and devices which transfer out-of-order.