From owner-freebsd-stable@FreeBSD.ORG Tue Jan 18 23:25:30 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0415416A4CE for ; Tue, 18 Jan 2005 23:25:30 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71E5F43D3F for ; Tue, 18 Jan 2005 23:25:27 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 66B278566C; Wed, 19 Jan 2005 09:55:25 +1030 (CST) Date: Wed, 19 Jan 2005 09:55:25 +1030 From: Greg 'groggy' Lehey To: Craig Boston , David Elsing , freebsd-stable@freebsd.org Message-ID: <20050118232525.GW79181@wantadilla.lemis.com> References: <20050118143302.GA99345@nowhere> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YwTTlJgQ7QoYB9ta" Content-Disposition: inline In-Reply-To: <20050118143302.GA99345@nowhere> User-Agent: Mutt/1.4.2.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 Subject: Re: Vinum Raid5 Init question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2005 23:25:30 -0000 --YwTTlJgQ7QoYB9ta Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tuesday, 18 January 2005 at 8:33:03 -0600, Craig Boston wrote: > On Tue, Jan 18, 2005 at 12:21:59PM +0100, David Elsing wrote: >> Quote from the manual of the 4th example of the chapter "HOW TO SET UP VINUM": >> "In addition, the volume specification includes the keyword >> setupstate, which ensures that all plexes are up after creation." Where does it tell you to do that? From the man page: setstate state [volume | plex | subdisk | drive] setstate sets the state of the specified objects to the specified state. This bypasses the usual consistency mechanism of vinum and should be used only for recovery purposes. It is possible to crash the system by incorrect use of this command. >> But a couple of weeks later I read the following in the manual: >> >> "Note that you must use the init command with RAID-5 plexes: otherwise >> extreme data corruption will result if one subdisk fails." > > Yes, this particular gotcha bit me a while back and I lost quite a bit > of data (my fault for not having good backups) due to it. IMO, I still > consider it a documentation bug though. That particular bit is buried > in a command reference section rather than being in bold in the "HOW TO" > guide. Yes, it could be clearer. Put in a PR. >> I read this to my horror after I filled the volume with data. You'll >> probably noticed I didn't init my volume. The disks are in good >> condition. The volume is almost filled to the maximum capacity. So a >> backup is a bit difficult due to the size of it. Are there any other >> options? If one disks fails, do I still get corrupted data? > > Yes, if one disk fails for any reason, every third sector will be > garbage and it's unlikely you'll be able to recover anything useful from > it. > > I would highly recommend backing up whatever is critically important to > you asap. If you like living dangerously and all the drives are in good > health, the parity data can be (theoretically) repaired with the "vinum > rebuildparity" command, but do so at your own risk... That did allow me > to recover a couple of my partitions that hadn't been trashed yet. This should work. Make sure the volume is not be mounted when you do so. > Also, if a good disk gets marked as "down" somehow before you can > correct this, whatever you do, do NOT issue a "vinum start" command > on it. In the current state of the array, that would be destructive > and irreversible. No, that's the correct way to do it. > That's what happened to me: ATA timeout caused one of the drives to > temporarily detach, corrupt filesystems caused a panic. If this > happens, you're better off using setstate to force it to up, as > wrong as that would normally be. I can't recall seeing a problem report. Greg -- See complete headers for address and phone numbers. --YwTTlJgQ7QoYB9ta Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB7ZrlIubykFB6QiMRAr9iAJ9kS0NrFM6JIAp19HC9cfntYo86AwCaA7HO Gm3vYbGKJrVdqLgeWrrAFlM= =Lj0q -----END PGP SIGNATURE----- --YwTTlJgQ7QoYB9ta--