Dal Allan dal_allan at mcimail.com
Tue Jul 9 21:13:29 PDT 1996

* From the SCSI Reflector, posted by:
* "Dal Allan" <dal_allan at mcimail.com>
Hi Gerry,

There is a lot of emotion tied into a technology called 'Redundant Disk', 
especially when it has been sold as protecting data. 

This idea smells of deferred errors and corruption opportunities. 

My gut reaction is that the subsystem is deliberately exposing itself to a 
corruption possibility during the act of making the data redundant. 

Suppose the system fails and the parity data has not been written to disk?

Suppose upon power up that one of the data drives is down? Will the data be 
recovered from the parity disk which has an invalid checksum?

Suppose upon power up the data drives are all good, will the invalid parity 
be detected? Will it have to wait until some time in the future when a data 
disk does go down? If so, corruption will be introduced at that time by 
recreating data from invalid parity. 

What if the controller which issued the immediate writes is the one which 
stays down after the power outage? You've got data that is updated and 
parity which represents how far back? 

Was Command Complete given back to the host for any commands which had 
parity data sitting in the controller cache when power went down? 

Am I missing something in the above scenarios? 

Why bother with the Immediate bit anyway? 

Look at the original concern that the parity drive becomes a bottleneck 
sometimes in RAID 5 and often in RAID 4. 

There is a documented solution to this already in use by some RAID vendors 
called Logging. It can be on all the time or only invoked when one disk 
becomes a bottleneck. You write all the data in a log area on a less busy 
disk and create a history which can be used to update parity during slack 
time or after power failure. It involves timestamps but the parity 
maintenance code is straightforward and a lot simpler than dealing with the 
specter of deferred errors. 

With so many things in parallel next week I may not be around for the 
discussion, but at this time consider me as playing on Steve's team. 


More information about the T10 mailing list