[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes: > Kalle Olavi Niemitalo <[EMAIL PROTECTED]> 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
