>
> On Fri, 24 Mar 2000, Mike Smith wrote:
>
> > >
> > > I searched the mailing list archive. I am not sure whether Vinum has
> > > solved the problem of atomic writes in a stripe to both the data fragment
> > > and parity fragment (RAID 5). In the case of a crash, you have no idea of
> > > where the writes have finished (even worse, a fragment may contain
> > > several sectors).
> >
> > This problem can't be solved with software-only RAID, and no (sensible)
> > software RAID implementation attempts to deal with it. Software RAID
> > reliability is predicated on the correct functioning of the system; it's
> > there to provide fault tolerance for the high-failure-rate hardware (eg.
> > disks).
>
> Thanks. It seems to me that you are saying software RAID can NOT cope with
> system crash and power failure? What about the Zebra filesystem or
> something like two-phase commit?
On a software RAID volume? That still has the same atomicity and
ordering issues, so it doesn't help. As far as filesystems are
concerned, you're still at the mercy of the local buffer cache and the
drives' caching behaviour.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message