Re: HEADS UP: Any umapfs users!

From: David Rhodus (drhodus_at_machdep.com)
Date: 03/30/04

  • Next message: Edwin Culp: "Re: apache13 signal 11 with php4 - with or without ssl" 
    Date: Tue, 30 Mar 2004 08:56:25 -0500
To: Peter Wemm <peter@wemm.org>

    On Mar 29, 2004, at 6:45 PM, Peter Wemm wrote:

    > I've just (slightly) pulled the rug out from underneath umapfs. It is
    > easy to bandaid to make it compile etc, but that doesn't solve the
    > serious fundamental problems inside. Basically, it has been suffering
    > from about 5 years of neglect in the tree, and is totally out of sync
    > with the vnode locking protocol.
    >
    > The problems are nasty. For starters, it has no vnode locking
    > implementation. It used to have a stub "NOP" shim that stopped
    > insta-panics for a while. However, the moment that a vnode is
    > reclaimed and goes inactive, we're guaranteed of a deadlock when it
    > calls vop_inactive on the underlying filesystem. (Or so I understand
    > from what Tim Robbins (tjr@) told me).
    >
    > For it to live on, it needs a caretaker who can go back and duplicate
    > the last 5 years worth of development that has been done to its
    > ancestor, nullfs. (umapfs is loosely derived from nullfs). It needs
    > real vnode locking - this is critical these days. It needs to be able
    > to survive in a full DEBUG_VFS_LOCKS kernel. Adding a bandaid is wrong
    > because it just takes it further in the wrong direction.

    I don't think there's any need to bandaid this filesystem Peter. All it
    needs is an all inspiring kernel hacker to step forward and do the
    work. That being said, if all the CS students haven't already been
    scared
    off by the FreeBSD development team. :-) I'd estimate this would take
    some that is looking for a good introduction to a part of the filesystem
    code about a day.

    Just take a snapshot of nullfs and copy it over and change it to use the
    underlying vmobject_t's directly via VOP_GETVOJECT. This works
    because there's no associated data with the upper vnode layer that's
    not present in the lower vnode layer. The stat information can be made
    to be reverse translated and passed back up because the credentials
    can just be crdup/cdmod down.

    -DR

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Edwin Culp: "Re: apache13 signal 11 with php4 - with or without ssl"