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

[Jeff Blaalid, CMD Technology, (714) 470-3155]

* 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.

    But, I would be happy with just the "reactive data" bit today!!

    Thanks for the great discussion - This is one of the biggests gaps
    in the SCSI storage specification.  When controllers own'ed the formats
    these were the tricks used to insure availability and accuracy of 
    the USER'S data.

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