Help with Vinum disk crash...

[Tony Frank]

Hi there,

On Wed, Feb 18, 2004 at 09:34:29AM +0100, Danny Carroll wrote:
> Quoting Greg 'groggy' Lehey <grog at 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 at 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