gvinum rebuildparity breakage

Ulf Lilleengen lulf at stud.ntnu.no
Tue Apr 3 09:46:31 UTC 2007


On Sat, Mar 31, 2007 at 01:11:16PM -0600, Rick C. Petty wrote:
> Due to ata driver problems, one of the disks which holds part of my RAID5
> volumes was dropped (see below).  gvinum did the right thing and reported
> the drive lost and all the relevent subdisks in my RAID5 plexes were
> changed to degraded.
*snip*
> 
> Problem 3).  I have four volumes which have degraded RAID5 plexes, as is
> expected from the dropped drive.  However the drive is up now but gvinum
> won't let me rebuild the parity:
> 
> # gvinum rebuildparity music.p0
> gvinum: plex music.p0 is not completely accessible
> 
> What a strange message, unless it's referring to the stale subdisk, but it
> won't let me do anything about that either:
> 
> # gvinum start music.p0.s0
> gvinum: can't start: cannot start 'music.p0.s0' - not yet supported
> 
> I'm not keen to try forcibly setting the state with "gvinum setstate -f"
> because: the man page states this is for diagnostic purposes only, and the
> man page doesn't give a list of possible states anyway.  This documentation
> has been lacking since the 5.x nerf of vinum/gvinum anyway so the man page
> and "gvinum help" are quite useless (Problem #4).  I'd rather not
> experiment with this command since the volumes are important, so I'm left
> without options.
> 
> So, how do I rebuild by RAID5 volumes?  This used to work fine in pre-geom
> vinum and I'm pretty sure this worked in gvinum at one point.  I'm running
> 6.1-STABLE (RELENG_6 as of 2006-Jul-21) with a GENERIC kernel.  Here is my
AFAIK resync/revive of subdisks is not yet implemented in gvinum. As you say,
forcing setstate won't do any good in this case. The easiest way out for you now
I think is to backup your data, and recreate the plex. Or, you could wait for a
patch. The latter may come in the near future.

-- 
Ulf Lilleengen


More information about the freebsd-geom mailing list