Re: NFS -- Hurd
Allover Stripes <allover@hedgehog.dyn.ez-ip.net> writes:
> If one translates this into some special file on the NFS server
> (say, every directory has a file ".hurd-passive-translators")
> containing the same information, you get the correct behaviour.
I was thinking of this too. It becomes more complex with hard
links though, since translators must be associated with the
inode.
".hurd-passive-translators" could be useful when serving diskless
machines whose /dev must be on the server. I've occasionally
done that with GNU/Linux, and there each /dev entry of a client
is kept as-is in a directory on the server. But if someone using
a client has permission to read a device, he can log on the
server and use the exported /dev directory to read the
corresponding device on the server. Saving the translators in a
separate file would prevent this.
Perhaps it would make sense to implement the
.hurd-passive-translators file with another translator running
over /hurd/nfs. That would give us translators on VFAT and
ISO9660 file systems too (once those are supported at all). But
every file access would then go through this extra wrapper, which
could slow things down.
Can passive translators be stacked with settrans -L like active
ones? That didn't seem to work when I tried.
> If the server happens to be a Hurd machine as well, the NFS server
> process may stumble across some passive translators in the underlying
> filesystem. If this happens, they just look like rather odd regular
> files. The client can't manipulate this part of the server's
> filesystem. Perhaps it should be able to; is this what you're
> asking?
It would seem logical to me if a /hurd/ext2fs translator set on
the server would be run on the server by nfsd, and the client saw
the contents of the file system as if it were part of the tree.
But since other translators (such as /hurd/symlink) must be shown
through, this may be too much to ask.
Reply to: