Date: Wed, 18 Feb 2004 22:16:53 +1100 From: Tony Frank <tfrank@optushome.com.au> To: Danny Carroll <danny@dannysplace.net> Cc: freebsd-questions@freebsd.org Subject: Re: Help with Vinum disk crash... Message-ID: <20040218111653.GB289@marvin.home.local> In-Reply-To: <1077093269.15aypd5fp76s@mailsrv.dannysplace.net> References: <00ed01c3f559$d7f1ac20$8052260a@capgemini.nl> <20040217223827.GM33797@wantadilla.lemis.com> <1077093269.15aypd5fp76s@mailsrv.dannysplace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi there,
On Wed, Feb 18, 2004 at 09:34:29AM +0100, Danny Carroll wrote:
> Quoting Greg 'groggy' Lehey <grog@FreeBSD.org>:
> > If this volume has only one plex, you're lost, unless you can bring up
> > the failed disk long enough to make a backup.
> Here is the output:
>
> 20 drives:
> D data1 State: up Device /dev/ad4s1a Avail: 3/109471 MB (0%)
> D ftp1 State: up Device /dev/ad4s1e Avail: 0/600 MB (0%)
> D www1 State: up Device /dev/ad4s1f Avail: 0/2048 MB (0%)
> D mail1 State: up Device /dev/ad4s1g Avail: 0/2048 MB (0%)
> D rback1 State: up Device /dev/ad4s1h Avail: 0/3072 MB (0%)
> D data2 State: up Device /dev/ad5s1a Avail: 6/109471 MB (0%)
> D ftp2 State: up Device /dev/ad5s1e Avail: 0/600 MB (0%)
> D www2 State: up Device /dev/ad5s1f Avail: 0/2048 MB (0%)
> D mail2 State: up Device /dev/ad5s1g Avail: 0/2048 MB (0%)
> D rback2 State: up Device /dev/ad5s1h Avail: 0/3072 MB (0%)
> D data3 State: up Device /dev/ad6s1a Avail: 6/109471 MB (0%)
> D ftp3 State: up Device /dev/ad6s1e Avail: 0/600 MB (0%)
> D www3 State: up Device /dev/ad6s1f Avail: 0/2048 MB (0%)
> D mail3 State: up Device /dev/ad6s1g Avail: 0/2048 MB (0%)
> D rback3 State: up Device /dev/ad6s1h Avail: 0/3072 MB (0%)
> D data4 State: up Device /dev/ad7s1a Avail: 6/109471 MB (0%)
> D ftp4 State: up Device /dev/ad7s1e Avail: 0/600 MB (0%)
> D www4 State: up Device /dev/ad7s1f Avail: 0/2048 MB (0%)
> D mail4 State: up Device /dev/ad7s1g Avail: 0/2048 MB (0%)
> D rback4 State: up Device /dev/ad7s1h Avail: 0/3072 MB (0%)
Ok, this is wrong - you really just want to define one vinum drive per
physical device.
Ie for a particular disk, give it a single 'vinum' partition using disklabel.
Then use different subdisks to split your space up.
> 5 volumes:
> V data State: up Plexes: 1 Size: 320 GB
This is should be ok - it means vinum thinks the volume is still accessable.
> 5 plexes:
> P data.p0 R5 State: degraded Subdisks: 4 Size: 320 GB
>From "man 4 vinum" :
degraded A RAID-5 plex entry which is accessible, but one subdisk
is down, requiring recovery for many I/O requests.
So you have a subdisk down which means Vinum can still read from the plex
but has to manually calculate the missing subdisk data.
> 20 subdisks:
> S data.p0.s0 State: stale PO: 0 B Size: 106 GB
> S data.p0.s1 State: up PO: 3924 kB Size: 106 GB
> S data.p0.s2 State: up PO: 7848 kB Size: 106 GB
> S data.p0.s3 State: up PO: 11 MB Size: 106 GB
Again from "man 4 vinum" :
stale A subdisk entry which has been created completely. All
fields are correct, the disk has been updated, and the
data was valid, but since then the drive has been crashed
and updates have been lost.
> I am only interested in the big one (data) the others were just for
> experimentation.... I thought since the plex was setup as raid5 it would be
> ok?
Yes, Vinum believes it can still access your data.
> I have 4 106gb subdisks, and see 318Gb of data... The 4th subdisk is
> becuase of the loss from Raid5 right?
Yes, one disk per stripe will be used for parity.
> Did I set this up incorrectly?
I suggest you read http://www.vinumvm.org/cfbsd/vinum.pdf - the last section
comments again on the particulars for drive & subdisk layout.
>From your original message:
>> When I do try and mount the volume, it says the following:
>>
>> [02:25 PM root@guard:/var/log]#mount /dev/vinum/data /usr/jails/ftp/data
>> mount: /dev/vinum/data on /usr/jails/ftp/data: incorrect super block
Typically I see this problem when trying to mount filesystem with incorrect type.
Was your filesystem ufs? If not you probably need to specify the type to mount
command using -t parameter. See "man 8 mount" for details.
Have you tried running fsck against the volume?
Assuming ufs filesystem, I'd suggest starting with:
fsck -n -t ufs /dev/vinum/data
Note the -n option tells fsck not to correct any errors but will give you an
indication about what is going on.
There are extra things you can try (recover using alternate super-block) but
perhaps wait and see the results first?
Another option would be to force the particular subdisk down and try the
above steps again.
Hope it helps,
Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040218111653.GB289>