Skip site navigation (1)Skip section navigation (2)
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>