Proposal to add a new modifier to SCSI Write commands. -Reply

[Milton Scritsmier]

* From the SCSI Reflector (scsi at symbios.com), posted by:
* Milton Scritsmier <milton at arraytech.com>
*
Jeff Blaalid, CMD Technology, wrote:
> 
> * From the SCSI Reflector (scsi at symbios.com), posted by:
> * "Jeff Blaalid, CMD Technology, (714) 470-3155" <BLAALID at cmd.com>
> *
> *
> > The real goal ...
> > "Mark the block" [to generate] "a CHECK
> > CONDITION when read".  "without having to
> > interfere with the data payload or ecc areas
> 
> >Hmmmmm.
> >
> >Thought 1: Totally cool idea.
> >
> >Thought 2 ...
> >
> >One of the toy projects I might finish if I were
> >independently wealthy would be to see how much of
> >SCSI I could implement as a layer on the host
> >side.  In particular by branching on x12 Inquiry
> >data to cope with the vagaries of specific
> >implementations.
> >
> >Doesn't this idea boil down to a bitmap of all
> >LBA's, stored outside of the LBA's, which the host
> >can edit?
> >
> >For LBA's that have a bit set, some i/o layer
> >generates a CHECK CONDITION when the LBA is
> >otherwise read OK?
> 
>     Yes - the final goal is to create tables on the 
>     disks (hiding blocks from the host) and placing
>     meta-data that can describe the "state of the data"
>     on the disk.
> 
>     But, the tables are very large (9+GBdisks) and
>     difficult to look at for each i/o operation.  
>     EG:  1 bit/block for a 9GB disk
>                 
>                 18874368 block     1 bit/block
>                 --------------- * ------------ = 4608 blocks or ~2.3 MB
>                 512 bytes/block    8 bits/byte
> 
>         Now this isn't much of a "storage loss" to the user but try 
>         maintaining this table for 42 devices or more from a RAID controller
>         or host.  The other problem is searching/indexing
>         this table for each and every operation.  It isn't difficult but
>         gets placed in the most critical execution path that will have
>         direct impact on QIO and spiral performance.
> 
>     Today many disk controllers (RAID) maintain the metadata on the
>     disk as you suggest but use the READL/WRITEL operations to create
>     ECC errors on the drive - thus a FLAG to tell them to check their
>     DATABASE.
> 
>     The goal of the "reactive data" is to have 
>     the drive "tell you to look" at your tables!
> 
>     Keep in mind that this approach is NOT limitted to "FORCED BAD" but
>     can be used to indicate all kinds of things - like XOR PARITY is not
>     correct...
> 
>     Finally, the ultimate solution would be a "FORMAT" specified HOST HEADER
>     overhead that would allow for this to be larger that ONE BIT.  The 
>     drive could (if enabled) generate CHECK CONDITION when any of the BITS 
>     are non-zero. This would allow the hosts to add whatever
>     they desired to each block.  Also, a READ modifier to do 
>     continous reads including the "HOST HEADER" information at the 
>     front of each block would be very nice.
> 

Hmm, but isn't this a bit clumsy when doing writes? At some point you may
have good data for a bad block sent to you by the host, or have regenerated
good parity, or whatever, and now you want to clear the condition. Putting
the bits in the header means taking an exception on the write, and then
issuing some kind of "block format" command to clear the header back to a
normal block header and perhaps writing the data you want in it.

You might have the drive understand it needs to do this when it sees a
normal write command to such a block (although it would still take extra
time). However, there may be some uses for these bits where you don't want
the drive to clear them automatically on writes, so it would be very
difficult to have the drive manage it.

As a partial solution, I might suggest using the WRITE LONG command to put
the info you want into the data area (giving you 512 bits of info), and then
munging the ECC bits to cause the read error. If the Transfer Block (TB)
bit is set in the Mode Select command, then on a read you get the error and
the data from the block should be in a buffer which tells you what the
problem is and (optionally) where to go in your table to deal with it.

On a write, the error magically goes away without any exception or extra
execution time at all. This is probably what you want for bad blocks and
for parity blocks which do not have valid parity. It may not solve all the
cases you want, however.


  Milton Scritsmier
  Array Technology, a division of EMC Corp.
  Boulder, CO
  
  milton at arraytech.com



*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com