From owner-freebsd-bugs@FreeBSD.ORG Tue Mar 30 16:46:36 2004 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A92FE16A4CE; Tue, 30 Mar 2004 16:46:36 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343F543D3F; Tue, 30 Mar 2004 16:46:36 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 50A022BD8D; Wed, 31 Mar 2004 10:46:33 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 87EC351224; Wed, 31 Mar 2004 10:16:30 +0930 (CST) Date: Wed, 31 Mar 2004 10:16:30 +0930 From: Greg 'groggy' Lehey To: Lukas Ertl , =?iso-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= Message-ID: <20040331004630.GA15929@wantadilla.lemis.com> References: <4068EA56.3060600@jonny.eng.br> <20040330053143.GN15929@wantadilla.lemis.com> <40697F3B.2020202@jonny.eng.br> <20040326222853.GA93269@zeus.faperj.br> <20040330143257.C72259@pcle2.cc.univie.ac.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="abYdCjSRCBwcb+dP" Content-Disposition: inline In-Reply-To: <40697F3B.2020202@jonny.eng.br> <20040330143257.C72259@pcle2.cc.univie.ac.at> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: bugs@FreeBSD.org cc: Joao Carlos Mendes Luis cc: stable@freebsd.org cc: hackers@freebsd.org cc: robert Subject: Re: Serious bug in vinum? X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2004 00:46:37 -0000 --abYdCjSRCBwcb+dP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tuesday, 30 March 2004 at 14:37:00 +0200, Lukas Ertl wrote: > On Fri, 26 Mar 2004, Joao Carlos Mendes Luis wrote: > >> I think this should be like: >> >> if (plex->state > plex_corrupt) { /* something = accessible, */ >> >> Or, in other words, volume state is up only if plex state is degraded >> or better. > > You are right, this is a bug, No, see my reply. > The correct solution, of course, is to check if the data is valid > before changing the volume state, but turn might turn out to be a > very complex check. Well, the minimum correct solution is to return an error if somebody tries to access the inaccessible part of the volume. That should happen, and I'm confused that it doesn't appear to be doing so in this case. On Tuesday, 30 March 2004 at 11:07:55 -0300, Joo Carlos Mendes Lus wrote: > Greg 'groggy' Lehey wrote: >> On Tuesday, 30 March 2004 at 0:32:38 -0300, Joo Carlos Mendes Lus wrote: >>> >> Basically, this is a feature and not a bug. A plex that is corrupt is >> still partially accessible, so we should allow access to it. If you >> have two striped plexes both striped between two disks, with the same >> stripe size, and one plex starts on the first drive, and the other on >> the second, and one drive dies, then each plex will lose half of its >> data, every second stripe. But the volume will be completely >> accessible. > > A good idea if you have both stripe and mirror, to avoid discarding t= he > whole disk. But, IMHO, if some part of the disk is inacessible, the volu= me > should go down, and IFF the operator wants to try recovery, should use the > setstate command. This is the safe state. setstate is not safe. It bypasses a lot of consistency checking. One possibility would be:=20 1. Based on the plex states, check if all of the volume is still accessible. 2. If not, take the volume into a "flaky" state. =20 3. *Somehow* ensure that the volume can't be accessed again as a file system until it has been remounted. 4. Refuse to remount the file system without the -f option. The last two are outside the scope of Vinum, of course. Discussion? -- Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --abYdCjSRCBwcb+dP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFAahTmIubykFB6QiMRApT4AJ95EOhURnt8Iw9gnFw8h17aU+G2QACgkkf1 0tqn+ehtbZoIOnfvK6Fhqqc= =ee6M -----END PGP SIGNATURE----- --abYdCjSRCBwcb+dP--