Date: Wed, 18 Feb 2004 13:15:18 +0100 From: Danny Carroll <danny@dannysplace.net> To: Tony Frank <tfrank@optushome.com.au> Cc: freebsd-questions@freebsd.org Subject: Re: Help with Vinum disk crash... Message-ID: <1077106518.yyrhxqeampw@mailsrv.dannysplace.net> In-Reply-To: <20040218111653.GB289@marvin.home.local> References: <00ed01c3f559$d7f1ac20$8052260a@capgemini.nl> <20040217223827.GM33797@wantadilla.lemis.com> <1077093269.15aypd5fp76s@mailsrv.dannysplace.net> <20040218111653.GB289@marvin.home.local>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Tony Frank <tfrank@optushome.com.au>: > 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 http://www.vinumvm.org/cfbsd/vinum.pdf - 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@guard:/usr/home/danny]#fsck /dev/vinum/data ** /dev/vinum/data ** Last Mounted on /usr/jails/ftp/data ** Phase 1 - Check Blocks and Sizes UNKNOWN FILE TYPE I=29 > > 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 ???
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1077106518.yyrhxqeampw>