On Wed, Oct 03, 2007 at 10:02:03PM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Oct 03, 2007 at 12:10:19PM -0700, Richard Elling wrote:
> > > -------------
> > > 
> > > # zpool scrub tank
> > > # zpool status -v tank
> > >   pool: tank
> > >  state: ONLINE
> > > status: One or more devices could not be used because the label is 
> > > missing or
> > >         invalid.  Sufficient replicas exist for the pool to continue
> > >         functioning in a degraded state.
> > > action: Replace the device using 'zpool replace'.
> > >    see: http://www.sun.com/msg/ZFS-8000-4J
> > >  scrub: resilver completed with 0 errors on Wed Oct  3 18:45:06 2007
> > > config:
> > > 
> > >         NAME        STATE     READ WRITE CKSUM
> > >         tank        ONLINE       0     0     0
> > >           raidz1    ONLINE       0     0     0
> > >             md0     UNAVAIL      0     0     0  corrupted data
> > >             md1     ONLINE       0     0     0
> > >             md2     ONLINE       0     0     0
> > > 
> > > errors: No known data errors
> > > # zpool replace tank md0
> > > invalid vdev specification
> > > use '-f' to override the following errors:
> > > md0 is in use (r1w1e1)
> > > # zpool replace -f tank md0
> > > invalid vdev specification
> > > the following errors must be manually repaired:
> > > md0 is in use (r1w1e1)
> > > 
> > > -----------------
> > > Well the advice of 'zpool replace' doesn't work. At this point the user 
> > > is now stuck. There seems to
> > > be just no way to now use the existing device md0.
> > 
> > In Solaris NV b72, this works as you expect.
> > # zpool replace zwimming /dev/ramdisk/rd1
> > # zpool status -v zwimming
> >    pool: zwimming
> >   state: DEGRADED
> >   scrub: resilver completed with 0 errors on Wed Oct  3 11:55:36 2007
> > config:
> > 
> >          NAME                        STATE     READ WRITE CKSUM
> >          zwimming                    DEGRADED     0     0     0
> >            raidz1                    DEGRADED     0     0     0
> >              replacing               DEGRADED     0     0     0
> >                /dev/ramdisk/rd1/old  FAULTED      0     0     0  corrupted 
> > data
> >                /dev/ramdisk/rd1      ONLINE       0     0     0
> >              /dev/ramdisk/rd2        ONLINE       0     0     0
> >              /dev/ramdisk/rd3        ONLINE       0     0     0
> > 
> > errors: No known data errors
> > # zpool status -v zwimming
> >    pool: zwimming
> >   state: ONLINE
> >   scrub: resilver completed with 0 errors on Wed Oct  3 11:55:36 2007
> > config:
> > 
> >          NAME                  STATE     READ WRITE CKSUM
> >          zwimming              ONLINE       0     0     0
> >            raidz1              ONLINE       0     0     0
> >              /dev/ramdisk/rd1  ONLINE       0     0     0
> >              /dev/ramdisk/rd2  ONLINE       0     0     0
> >              /dev/ramdisk/rd3  ONLINE       0     0     0
> > 
> > errors: No known data errors
> 
> Good to know, but I think it's still a bit of ZFS fault. The error
> message 'md0 is in use (r1w1e1)' means that something (I'm quite sure
> it's ZFS) keeps device open. Why does it keeps it open when it doesn't
> recognize it? Or maybe it tries to open it twice for write (exclusively)
> when replacing, which is not allowed in GEOM in FreeBSD.
> 
> I can take a look if this is the former or the latter, but it should be
> fixed in ZFS itself, IMHO.

Ok, it seems that it was fixed in ZFS itself already:

        /*
         * If we are setting the vdev state to anything but an open state, then
         * always close the underlying device.  Otherwise, we keep accessible
         * but invalid devices open forever.  We don't call vdev_close() itself,
         * because that implies some extra checks (offline, etc) that we don't
         * want here.  This is limited to leaf devices, because otherwise
         * closing the device will affect other children.
         */
        if (vdev_is_dead(vd) && vd->vdev_ops->vdev_op_leaf)
                vd->vdev_ops->vdev_op_close(vd);

The ZFS version from FreeBSD-CURRENT doesn't have this code yet, it's only in
my perforce branch for now. I'll verify later today if it really fixes the
problem and I'll report back if not.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
[EMAIL PROTECTED]                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Attachment: pgpqzqbHn0DZG.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to