> 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!)
