Date: Fri, 24 Mar 2000 11:00:56 -0800 From: Mike Smith <msmith@freebsd.org> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Software RAID and vinum Message-ID: <200003241900.LAA01113@mass.cdrom.com> In-Reply-To: Your message of "Fri, 24 Mar 2000 11:27:25 EST." <Pine.GSO.3.96.1000324110754.1834B-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003241900.LAA01113>