Help with Vinum disk crash...

Danny Carroll danny at
Wed Feb 18 04:21:52 PST 2004

Quoting Tony Frank <tfrank at>:
> 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.

I was afraid of that....  Noted

> > 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.

That is what I thought, but it wond mount, see below...

> 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.

But I assume it cant write till I replace it..

> 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 - the last section
> comments again on the particulars for drive & subdisk layout.
> 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.

fsck -n -t ufs did not work...    Seems like fsck does not know -t ...
You dont want to see the output from that...  Nearly every inode has problems..

I ran it without the -n and the first entry looks like this:

UNKNOWN FILE TYPE I=188225^C[12:39 PM root at guard:/usr/home/danny]#fsck
** /dev/vinum/data
** Last Mounted on /usr/jails/ftp/data
** Phase 1 - Check Blocks and Sizes

> There are extra things you can try (recover using alternate super-block) but
> perhaps wait and see the results first?

How do I read an alternative superblock wih a vinum drive???

> Another option would be to force the particular subdisk down and try the
> above steps again.

Something like:

vinum down data.p0.s0 ???

More information about the freebsd-questions mailing list