nullfs and named pipes.

Josef Karthauser joe at FreeBSD.org
Sun Feb 18 22:42:07 UTC 2007


On Fri, Feb 16, 2007 at 04:36:56PM +0200, Kostik Belousov wrote:
> > >>    cvs diff: Diffing .
> > >>    Index: null_subr.c
> > >>    ===================================================================
> > >>    RCS file: /home/ncvs/src/sys/fs/nullfs/null_subr.c,v
> > >>    retrieving revision 1.48.2.1
> > >>    diff -u -r1.48.2.1 null_subr.c
> > >>    --- null_subr.c 13 Mar 2006 03:05:17 -0000      1.48.2.1
> > >>    +++ null_subr.c 14 Feb 2007 00:02:28 -0000
> > >>    @@ -235,6 +235,8 @@
> > >>	    xp->null_vnode = vp;
> > >>	    xp->null_lowervp = lowervp;
> > >>	    vp->v_type = lowervp->v_type;
> > >>    +       if (vp->v_type == VSOCK || vp->v_type == VFIFO)
> > >>    +               vp->v_un = lowervp->v_un;
> > >
> > >I'm wondering is some reference counting needed there ?
> > 
> > Yes, I find this a bit worrying also, but I don't know enough about how 
> > nullfs works to reason about it.  What happens when a vnode in the bottom 
> > layer has its on-disk reference count drop to zero -- is the vnode in the 
> > top layer invalidated somehow?
> 
> Vnode reclamation from lower layer cannot do anithing for corresponding nullfs
> vnode, but that vnode has reference from nullfs vnode.
> On the other hand, can forced unmount proceed for lower layer ?

Does know of any reason why I can't commit this as it is, at least for
now.  It doesn't appear that it would break anything that works
currently, and in its current form it at least fixes named pipe
functionality for the kinds of cases that people would want to use it.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070218/65e99896/attachment.pgp


More information about the freebsd-fs mailing list