Re: NFS -- Hurd
Roland McGrath <roland@gnu.org> writes:
> > 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.
Well, if you are willing to put up with a little more cruft on top of
what NFS feeds you, you *can* have it both ways. Supporting magic
translator files would allow Hurd clients to support translators even
when using Hurd-ignorant servers; it would allow Hurd servers to
export translated files to Hurd-ignorant clients. It would also be
gruesome. But I like it.
> 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 know, I'm still looking forward to shadowfs... although shadowfs
systems have a reputation for being inefficient.
tb@MIT.EDU (Thomas Bushnell, BSG) writes:
> Allover Stripes <allover@hedgehog.dyn.ez-ip.net> writes:
>
> > 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?
>
> Well, this is the current behavior of Sun NFS and most others; it
> would have to be a configuration option for the server which way you
> wanted it to run.
Ah, I understand now. I'm used to the Debian GNU/Linux setup, where
(possibly as a result of having a pure user-space client) mount points
are just like any other directory. Alas, people are most likely to
compare Debian GNU/Hurd to Debian GNU/Linux and wonder why things are
different.
> > That wasn't very clear. Suppose I have the following: antelope is
> > running an NFS server. It exports /visible and everything under it.
> > caribou is running an NFS client, importing the tree as /nfs. Now
> > suppose the following occur: antelope:/visible/bsd has a translator
> > set to "/bin/ufs /dev/hd0s3". Then if caribou tries to read and write
> > caribou:/nfs/bsd, it starts a translator trying to read and write
> > caribou's /dev/hd0s3.
>
> Yes, that's right. This is thus a little more live than the Sun NFS
> (for which the client doesn't see a mount at all). A server option
> could usefully set whether the client ever sees a translator.
I guess my problem is that this may do the catastrophically wrong
thing. At best you'll get a confusing error message.
> > Some nightmares are to be expected when using NFS; but is this really
> > the Right Thing?
>
> Possibly not. NFS handles mount points poorly, and the flexibility of
> translators makes it even harder to decide just what the Right Thing
> is. The best I can think of is a plethora of server options so users
> can pick which form of confusion they prefer.
Moreover, I should stop pestering Hurd developers about this; it's the
sort of thing users can play with, and the current behaviour will be
fine in most situations.
Is there any reason we shouldn't just use the Debian standard NFS
server (supposing that we don't care about NFS translators)? Does it
compile okay with no modifications?
Andrew
Reply to: