Okay, looks like I might have a *good* one here ... inode hang

Marc G. Fournier scrappy at hub.org
Mon Jul 7 16:33:05 PDT 2003


'k, since this one sounds like it may be a painful one to fix, I'm doign
the same thing using an nfs mount for now, which, unless I'm missing
something, does the same thing with a but more net traffic ... ?

the reason I am/was using nullfs was to get at the "top files" of the
union mount for backup purposes ...

On Mon, 7 Jul 2003, Tim Robbins wrote:

> On Mon, Jul 07, 2003 at 01:05:30AM -0700, David Schultz wrote:
>
> > On Thu, Jul 03, 2003, Marc G. Fournier wrote:
> > > > follow that one, too.  Maybe the trail will simply lead back to
> > > > unionfs...
> > >
> > > 'K, how about a loop?
> >
> > Heh...it's a deadlock between unionfs and nullfs.  Sheesh.
> > If unionfs is at fault here, I think I already know where
> > the problem is, and it isn't easy to fix.  But I'll have to
> > look more carefully when I get a chance.
>
> nullfs on 4.x can probably deadlock in certain situations while attempting to
> recycle vnodes; see null_vnops.c 1.63. This bug was made more obvious in
> 5.x by null_vnops.c 1.51, but I'm pretty sure that the problem was still
> there in earlier versions, but was just harder to trigger.
>
> There are a few questionable things in unionfs too. There might be a race in
> union_inactive() (should it grab the vnode interlock before dropping
> the vnode lock and call vgonel() instead of vgone()?), and the support for
> locking stacks of vnodes seems to be #if 0'd out in union_lock().
>
>
> Tim
>


More information about the freebsd-stable mailing list