Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c

From: Terry Lambert (tlambert2_at_mindspring.com)
Date: 06/19/03

  • Next message: David Schultz: "Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c" 
    Date: Thu, 19 Jun 2003 01:57:16 -0700
To: "Marc G. Fournier" <scrappy@hub.org>

    "Marc G. Fournier" wrote:
    > On Thu, 19 Jun 2003, Tim J. Robbins wrote:
    > > At least one of the sections is well-deserved: umapfs is horribly broken
    > > on -current, and only works by accident on previous releases. I'm
    > > actually considering putting an even stronger warning on that one. The
    > > others (null and union) aren't nearly as bad, and have been fixed
    > > significantly since the notice was put on the manpages.
    >
    > what is umapfs? I don't have a man page for that one on my 4.x box ... ?

    The umapfs attempts to map user ids between one namespace
    and another, such as you might need to do when merging a
    company, each with a UNIX box, with intersecting UID sets
    with collisions (i.e. is uid 105 "john" or "frank"?). Using
    umapfs, you can have both "john" and "frank" keep their local
    accounts, and for network mounts, translate the uid space to
    present a different view on it.

    The umapfs is actually just another toy FS (per my other
    posting inre: unionfs-not-union and nullfs).

    You could easily "fix" umapfs by copying the nullfs code,
    and using the underlying vmobject_t's directly via
    VOP_GETVOJECT, since there is no data associated with the
    upper vnode that's not in the lower vnode. The translation
    and lookup would need to be done in two more places than it
    is now, so there would be a slightly increased performance
    penalty over that of unionfs.

    The only thing you really care about is the credentials,
    which can be crdup/crmod on the way down, and the stat
    information when can be reverse translated and passed back
    up.

    This would probably take about a day to implement, and it
    would be a good introduction to the code for anyone who thinks
    there aren't real problems that can't be avoided without some
    architectural changes.

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

  • Next message: David Schultz: "Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c"