problem adding subdisk to vinum

Shawn Ostapuk flagg at slumber.org
Wed Aug 13 19:02:28 PDT 2003


> > su-2.03# vinum lv -r
> > V pr0n                  State: up       Plexes:       1 Size:       1172 GB
> > P vinum0.p0           C State: up       Subdisks:    11 Size:       1172 GB
> > S vinum0.p0.s00         State: up       PO:        0  B Size:        152 GB
> > S vinum0.p0.s01         State: up       PO:      152 GB Size:         28 GB
> > S vinum0.p0.s02         State: up       PO:      181 GB Size:         76 GB
> > S vinum0.p0.s03         State: up       PO:      257 GB Size:         76 GB
> > S vinum0.p0.s04         State: up       PO:      333 GB Size:         76 GB
> > S vinum0.p0.s05         State: up       PO:      410 GB Size:         76 GB
> > S vinum0.p0.s06         State: up       PO:      486 GB Size:         76 GB
> > S vinum0.p0.s07         State: up       PO:      562 GB Size:         74 GB
> > S vinum0.p0.s08         State: up       PO:      637 GB Size:        233 GB
> > S vinum0.p0.s08         State: up       PO:      637 GB Size:        233 GB
> > S vinum0.p0.s09         State: up       PO:      871 GB Size:        152 GB
> > S vinum0.p0.s10         State: up       PO:     1023 GB Size:        149 GB
> >
> > Either method results in an umountable and unaccessable filesystem.
> >
> > su-2.03# mount /dev/vinum/pr0n /data
> > mount: /dev/vinum/pr0n on /data: incorrect super block
> >
> > su-2.03# fsck /dev/vinum/pr0n
> > ** /dev/vinum/pr0n
> >
> >  CANNOT READ: BLK 16
> >  CONTINUE? [yn] ^C
> 
> That's with the states shown above?  Really?  Are there any log
> messages?

Yes with the states shown above. The above is a copy and paste of
successive commands i went through for the email response :) No 
errors are reported to console, stderr, or any of the log files in
/var/log/ including messages. I have dug around considerably
looking for some sort of clue that would help lead me in some
direction to fix this problem - can't find any errors other than
the filesystem being inaccessable.

> >> OK.  Start from your last status (volume up, plex corrupt, last
> >> subdisk empty).  Set plex and last subdisk to up.  Run fsck and tell
> >> me what you get.  If that works, try growfs.  If that workds, do a
> >> saveconfig.
> >
> > I've probably added the new disk over 100 times now trying every
> > possible option. ...
> 
> Despite all this, it still looks like pilot error to me.  Are you very
> sure that every object in your volume was "up" when you tried that
> fsck?  Are they still up afterwards?  No log messages?

I'd love for it to my fault right now if it meant i could get past this
:) But honestly I think i've gotten pretty used to vinum over the years
and can't figure out what i could be doing wrong.

And I am absolutely positive when I try to access the filesystem, ALL
the states are up, _exactly_ like above. Trying to fsck/mount or
anything else does not cause the states to change -- they remain up
until i destroy/recreate the config and the new drive defaults back to
emtpy.

Again, the above is _exactly_ (copied and pasted) right before i
attempted the fsck and mount above (copied and pasted). I've been
staring at vinum lists's for days now and over and over again it is no
problem getting it with all the states up, it just seems my filesystem
disappears whenever the new drive is on there (which makes no sense to
me because it IS at the end).

Shawn


More information about the freebsd-questions mailing list