Re: NFS -- Hurd
tb@MIT.EDU (Thomas Bushnell, BSG) writes:
> Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:
<snip>
> > When the client sets the passive translator of a file to
> > "/hurd/ext2fs /dev/hd0s2", the server must not attempt to
> > activate the translator when the file is accessed.
>
> Quite right.
>
> If you look at the implementation of the NFS lookup call in the Hurd
> nfsd (hurd/nfsd/ops.c:op_lookup) you will see that the server uses
> O_NOTRANS to prevent such activation.
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?
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. At best it returns an error message; at worst
severe lossage occurs. Alternatively, suppose antelope:/visible/foo
has its translator set as /visible/bar. Then caribou:/nfs/foo
apparently has its translator set to teh nonexistent /visible/bar. If
you then set caribou:/nfs/foo's translator to /nfs/bar, reading the
file works on caribou but not on antelope.
Some nightmares are to be expected when using NFS; but is this really
the Right Thing?
I still like the "no translators over NFS" approach; you'd then just
splat a shadow RAM filesystem over top containing your translators.
Andrew Archibald
Reply to: