Date: Mon, 23 Feb 2004 14:57:40 +1030 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Tony Frank <tfrank@optushome.com.au> Cc: Danny Carroll <danny@dannysplace.net> Subject: Re: Help with Vinum disk crash... Message-ID: <20040223042740.GT87020@wantadilla.lemis.com> In-Reply-To: <20040218140429.GG289@marvin.home.local> References: <00ed01c3f559$d7f1ac20$8052260a@capgemini.nl> <20040217223827.GM33797@wantadilla.lemis.com> <1077093269.15aypd5fp76s@mailsrv.dannysplace.net> <20040218111653.GB289@marvin.home.local> <1077106518.yyrhxqeampw@mailsrv.dannysplace.net> <20040218140429.GG289@marvin.home.local>
next in thread | previous in thread | raw e-mail | index | archive | help
--TVVcQco/7vcH19KK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 19 February 2004 at 1:04:29 +1100, Tony Frank wrote: > Hi, > > On Wed, Feb 18, 2004 at 01:15:18PM +0100, Danny Carroll wrote: >> Quoting Tony Frank <tfrank@optushome.com.au>: > >>> So you have a subdisk down which means Vinum can still read from the plex >>> but has to manually calculate the missing subdisk data. >> But I assume it cant write till I replace it.. > > I believe it should function for both read & write in degraded mode. > Any reads will have to be rebuilt hence there will be a big hit in > performance. No, only reads of the missing disk need to be rebuilt. There's a detailed discussion of how RAID-5 works in degraded mode at http://www.vinumvm.org/vinum/implementation.html . >>> Another option would be to force the particular subdisk down and try the >>> above steps again. >> Something like: >> >> vinum down data.p0.s0 ??? > > The command would be "vinum stop data.p0.s0" > In my case I had to do "vinum stop -f data.p0.s0" I'm not sure what would happen here, but it could be dangerous. The object is already inaccessible. The different states are maintained for two main reasons: 1. It tells the user how they got like that. 2. It tells Vinum whether the data on the object, if accessible, is still up to date. "Crashed" and "down" mean that the data is up to date, so a 'start' can complete immediately. "Obsolete" and "stale" mean that the data is no longer up to date. If you change the state of a subdisk from "stale" to "down" and then issue a start command, Vinum assumes that the object still contains the correct data, so it sets it "up" with no change. This will result in severe data corruption of the kind that you're seeing. > However this should not have any impact to your situation. The > volume is working at the Vinum level (although degraded) The problem > here is that the data on the vinum volume appears to be somehow > corrupt. Correct. I'm wondering if this happened as the result of something else, possibly finger trouble. The answer might be in the missing information asked for at http://www.vinumvm.org/vinum/how-to-debug.html. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --TVVcQco/7vcH19KK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFAOYE8IubykFB6QiMRAug5AJwM6aS1jNazODNQCsGAtF5sYC1lrQCeMO/3 n4ioMgEeVIEfo8HQV0LIJmc= =dHGO -----END PGP SIGNATURE----- --TVVcQco/7vcH19KK--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040223042740.GT87020>