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