Date: Mon, 27 Jun 2005 15:45:19 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: freebsd-current@freebsd.org Subject: Re: Unable to umount union-parts after umounting unionfs Message-ID: <20050627134519.GR1283@obiwan.tataz.chchile.org> In-Reply-To: <20050625141320.GA605@fasolt.home.paeps.cx> References: <20050622065357.GA694@loge.nixsys.be> <20050623083804.GV738@obiwan.tataz.chchile.org> <20050623104843.GA698@loge.nixsys.be> <20050623142117.GE738@obiwan.tataz.chchile.org> <20050625141320.GA605@fasolt.home.paeps.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 25, 2005 at 04:13:20PM +0200, Philip Paeps wrote:
> On 2005-06-23 16:21:17 (+0200), Jeremie Le Hen <jeremie@le-hen.org> wrote:
> > > > Could you show us the locked vnodes for these two cases please ?
> > >
> > > Is there any way I can either try to unmount the filesystem manually from
> > > the debugger or make the unmounting code more chatting about what it's
> > > waiting for?
> >
> > I don't think that having a snapshot of locked vnode when union_unmount() is
> > called would inform us further. However, I you want to try, you just have
> > to drop to DDB, set a breakpoint on union_unmount() (typing "break
> > union_unmount") and then try the unmount (you can delete the breakpoint by
> > simply using "delete union_unmount").
>
> Note that the problem is not in unmounting the union filesystem, that works
> fine, it's unmounting the top layer. Unmounting the bottom layer is not a
> problem either.
Ah, I misread. This is the expected behaviour : the top layer is
obviously busy while the unionfs mount is active. Here is the same
setup that you first described :
%%%
/dev/md0 on /root/tests/mnt0 (ufs, local)
/dev/md1 on /root/tests/mnt1 (ufs, local)
<above>:/root/tests/mnt1 on /root/tests/mnt0 (unionfs, local, noclusterw)
%%%
Imagine what would happen to the unionfs mount if /root/tests/mnt1 was
unmounted. This is nonsense.
> %%%
> vflush: busy vnode
> 0xc2578bb0: tag ufs, type VDIR
> usecount 1, writecount 0, refcount 4 mountedhere 0
> flags (VV_ROOT)
> VI_LOCKed v_object 0xc256c630 ref 0 pages 1
> lock type ufs: EXCL (count 1) by thread 0xc2547900 (pid 687)
> ino 2, on dev md1
> %%%
This is a bug, I can reproduce it here. I am not enough skilled to
correct this filesystem. It has been known to be broken for a long
time and I expect things goes bader with time, as the second
thermothynamics principle states :-).
Regards,
PS: I'm willing to try to foreport FiST [1] to FreeBSD 6, it is known
to have, among others, a very good union filesystem implementation,
very well tested with POSIX test suite [2] (you may want to have a look
to the whole thread, it's quite interesting IIRC). It only works on
FreeBSD 4 and FreeBSD 5 ATM and it needs to include phk's changes to
the VFS to be compiled on CURRENT.
[1] http://www.filesystems.org/
[2] http://lists.freebsd.org/pipermail/freebsd-fs/2005-March/000959.html
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050627134519.GR1283>