From owner-freebsd-hackers Sun Jul 19 00:08:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA09294 for freebsd-hackers-outgoing; Sun, 19 Jul 1998 00:08:12 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA09190 for ; Sun, 19 Jul 1998 00:07:44 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id QAA00806; Sun, 19 Jul 1998 16:37:03 +0930 (CST) Message-ID: <19980719163703.G435@freebie.lemis.com> Date: Sun, 19 Jul 1998 16:37:03 +0930 From: Greg Lehey To: Terry Lambert 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 References: <19980715094757.P15083@freebie.lemis.com> <199807150656.XAA08080@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807150656.XAA08080@usr06.primenet.com>; from Terry Lambert on Wed, Jul 15, 1998 at 06:56:10AM +0000 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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