Date: Sun, 19 Jul 1998 16:37:03 +0930 From: Greg Lehey <grog@lemis.com> To: Terry Lambert <tlambert@primenet.com> Cc: wilko@yedi.iaf.nl, gibbs@plutotech.com, andre@pipeline.ch, Matthew.Alton@anheuser-busch.com, Hackers@FreeBSD.ORG Subject: Re: Software RAID-5 performance Message-ID: <19980719163703.G435@freebie.lemis.com> In-Reply-To: <199807150656.XAA08080@usr06.primenet.com>; from Terry Lambert on Wed, Jul 15, 1998 at 06:56:10AM %2B0000 References: <19980715094757.P15083@freebie.lemis.com> <199807150656.XAA08080@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 15 July 1998 at 6:56:10 +0000, Terry Lambert wrote: >>> You now have an inconsistent raid5 set. >> >> Correct. Similar things happen if a disk loses power while writing, >> but the window is larger for RAID-5, and it's much more difficult to >> detect. There are a number of "solutions", of course: >> >> 1. Intent logging. Save some copy of the data elsewhere first. >> Slow. > > You can actually "containerize" this. You end up with something that > looks a lot like IBM's JFS. > > The basic idea is that you create a "container" that points to the > old object; then you update the new object to a new location, rewrite > the container, and free up the old object. Right. That was roughly what I was thinking of. Veritas does this by writing an intent log in a specific place in the file system. >> 3. As long as the disks didn't physically fail, rebuild the RAID-5 >> set after rebooting. >> >> None of these is nice. > > Unfortuantely, if you relied on this last approach, you wouldn't be > able to tell a soft failutre from a hard failure. Right. You would have to assume it was a hard failure every time. > VXFS (Veritas) on UnixWare used to have this problem; it assumed > that all soft failures would be resolved transparently (an incorrect > assumption). On slow IDE disks, the orginal 1.0 release had a habit > of eating "/usr" and marking it bad. So *that*'s what happened. I gave up VxFS for a long time as a result of that particular bug. > Unfortunately, you could undo this without a low level format. Could or couldn't? I undid it by moving to ufs :-) Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key 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?19980719163703.G435>