"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Tue, 11 Jan 2000 15:03:03 +0100, mauelsha
> <[EMAIL PROTECTED]> said:
>
> >> THIS IS EXPECTED. RAID-5 isn't proof against multiple failures, and the
> >> only way you can get bitten by this failure mode is to have a system
> >> failure and a disk failure at the same time.
>
> > To try to avoid this kind of problem some brands do have additional
> > logging (to disk which is slow for sure or to NVRAM) in place, which
> > enables them to at least recognize the fault to avoid the
> > reconstruction of invalid data or even enables them to recover the
> > data by using redundant copies of it in NVRAM + logging information
> > what could be written to the disks and what not.
>
> Absolutely: the only way to avoid it is to make the data+parity updates
> atomic, either in NVRAM or via transactions. I'm not aware of any
> software RAID solutions which do such logging at the moment: do you know
> of any?
>
AFAIK Veritas only does the first part of what i mentioned above
(invalid
on disk data recognition).
They do logging by default for RAID5 volumes and optionaly also for
RAID1 volumes.
In the RAID5 (with logging) case they can figure out if an n-1 disk
write took place and can
rebuild the data. In case an n-m (1 < m < n) took place they can
therefore at least
recognize the desaster ;-)
In the RAID1 (with logging) scenario they are able to recognize, which
of the n mirrors have actual
data and which ones don't to deliver the actual data to the user and to
try to make
the other mirrors consistent.
But because it's a software solution without any NVRAM support they
can't
handle the data redundancy case.
Heinz
