Re: NFS -- Hurd
> Hmmm. Is this really a good idea? Won't this cause problems if, for
> example, there's a "mount point" in the filesystem being served? What
> if the server really does want to run translators? Say, it wants to
> export via NFS its BSD filesystem; would it then send raw disk blocks
> across the network for the client to translate?
You can't have it both ways, and having the server using O_NOTRANS is
definitely what you want in some cases.
The issues here, and the details of what might happen in the scenario you
presented, are really basically the same as the issues of mount points and
device special files in NFS on Unix. Traditionally, Unix NFS servers have
not resolved mount points--the client must separately mount the filesystem
from the NFS server as a top-level name using the "mount" SunRPC protocol
(so that the client needs a distinct `mount' call with a distinct
/etc/exports check on the server to get the mounted filesystem). I know of
no Unix NFS server that opens device special files on the server--in fact,
all NFS diskless-booting schemes depend on the fact that the server
delivers the major/minor device numbers for device special files to the
client so that the client can access its own devices.
The bottom line is that there are arguments for both approaches and one
really probably wants somewhere in between, but we are not breaking any new
ground and would be incompatible to do differently than we are now doing.
The important thing to realize is that the rest of the Hurd (including the
parts that aren't there yet ;-) gives you the flexibility to have it both
ways, if you can wrap your head around enough levels of indirection. You
can use something along the lines of shadowfs to create a virtual
filesystem providing a directory tree with no visible translators, made up
of the post-translator apparent contents of some real directory tree, and
have nfsd export that virtual directory. You can make shadowfs, or
whatever that translator turns out to be, arbitrarily configurable as to
which translators to silently follow and which ones to expose to clients.
> I still like the "no translators over NFS" approach; you'd then just
> splat a shadow RAM filesystem over top containing your translators.
That is certainly a good approach to make the most of the situation with
existing NFS servers. If you want a really cheap and sleazy kludge, you
can make device files on the NFS server, and then write the /hurd/blkdev
and /hurd/chrdev translators as simple scripts that index the major/minor
device numbers into a table of translator command lines to exec. (I told
you it was sleazy!)
Reply to: