From owner-freebsd-fs Mon Nov 15 11:52:54 1999 Delivered-To: freebsd-fs@freebsd.org Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id 0AAC114BD5 for ; Mon, 15 Nov 1999 11:52:48 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id GAA21345; Tue, 16 Nov 1999 06:22:34 +1030 (CST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991115145200.09633@mojave.sitaranetworks.com> Date: Mon, 15 Nov 1999 14:52:00 -0500 From: Greg Lehey To: Bernd Walter Cc: Mattias Pantzare , freebsd-fs@FreeBSD.ORG Subject: Re: RAID-5 and failure Reply-To: Greg Lehey References: <199911061716.SAA20783@zed.ludd.luth.se> <19991106183316.A9420@cicely7.cicely.de> <19991113213325.57908@mojave.sitaranetworks.com> <19991115203828.B5417@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <19991115203828.B5417@cicely7.cicely.de>; from Bernd Walter on Mon, Nov 15, 1999 at 08:38:28PM +0100 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 15 November 1999 at 20:38:28 +0100, Bernd Walter wrote: > On Sat, Nov 13, 1999 at 09:33:25PM -0500, Greg Lehey wrote: >> >> 4. The system crashes after writing the first data block for a RAID-5 >> stripe and before writing the last data block. >> >> When the system comes up, both data and parity are inconsistent. >> >> 5. The system crashes after writing the last data block for a RAID-5 >> stripe and before writing the last parity block. >> >> When the system comes up, data is consistent, and parity is >> inconsistent. >> >> There are a number of ways of dealing with situations 4 and 5. The >> real problem is that they only occur when the system crashes, so >> whatever recovery information is required must be stored in >> non-volatile storage. Some systems do include a NOVRAM for this kind >> of information, but in general purpose systems the only possibility is >> to write the information to disk, which would make the inherently slow >> RAID-5 write even slower. My attitude here is that RAID-5 writes are >> comparatively infrequent, and so are crashes. In the case of (5), you >> could rebuild parity after a crash. In the case of (4), I have no >> good answer. Suggestions welcome. > > Case 4 is not that different from case 5 as any differences should be > handled by the FS using the volume. The problem is that in case 4 you don't have anything to go by. You don't know which data are inconsistent unless you keep a log. The FS using the volume has followed the kernel into the eternal bit bucket. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message