vfsx17.patch available - continuing vfs work (expert developers only)
qhwt+dfly at les.ath.cx
Fri Nov 5 02:47:25 PST 2004
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
(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.
More information about the Kernel