Date: Thu, 19 Jun 2003 01:57:16 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Marc G. Fournier" <scrappy@hub.org> Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c Message-ID: <3EF17AEC.D3AC9D3F@mindspring.com> References: <20030618112226.GA42606@fling-wing.demos.su> <20030618121620.GG835@starjuice.net><20030618231640.T8920@hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EF17AEC.D3AC9D3F>