Re: vfsx17.patch available - continuing vfs work (expert developers only)

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

Hi.
On Thu, Nov 04, 2004 at 11:12:20PM -0800, Matthew Dillon wrote:
>     The next patch is ready.  I haven't dealt with the nfs server, unionfs,
>     or nullfs yet, I've been working around the edges cleaning things up.
> 
> 	fetch http://leaf.dragonflybsd.org/~dillon/vfsx17.patch

I'm running make -j100 buildworld with /usr/obj NFS-lookback mounted
from /home/nfs to see if it survives (the previous one didn't finish).
I'll run other benchmarks on that mount point if it's finished.

One thing I noticed is that, with the following line in /etc/exports
/home/nfs 127.0.0.1

(and is mounted to /usr/obj) one would usually get `permision denied'
(unless you specified one of -map* options) if you for example try to create
a file on the NFS mounted filesystem as root; with vfsx17.patch, it creates
a file with uid = 4294967296 instead.  Is this normal?

And if I changed the directory permission on /home/nfs, the permission
was not propagated to /usr/obj until I restarted mountd. I don't remember
if the same thing happens on other systems, though.

>     Maintaining an unbroken topology also has an interesting side effect in
>     that it becomes possible to safely export multiple subdirectories of
>     the same filesystem with *different* export permissions, without having
>     to hand the whole filesytem to the client... something that cannot be
>     done with most existing NFS servers.  I don't plan on implementing the
>     feature myself, I have to move onto the other items on my list, but I 
>     will write it up for anyone who wants to have a go at it once I get
>     the NFS server working properly again.

That's a very nice feature to have! Every time I edit exports file, it
never did what I wanted until I cut it down to a single entry.