Re: NFS -- Hurd
Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:
> 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.
Excellent idea! I like it!
And we don't have to convince the Hurd maintainers, either; the thing
to do now is to just write the silly thing. Now I really need to get
the Hurd up and running...
> > 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.
As you say, that's what the current Linux userland nfsd does.
Symlinks are an interesting problem; my nfsd just returns them as
symlinks. But that sometimes does unexpected things; for example, I
had a symlink to /usr being exported; on the remote machine, it
pointed to a different directory. Using this scheme for translators,
you get two kinds of symlinks, both of which do precisely what a naive
user expects.
How hard is it to write a translator? I remember (months ago) Gordon
Matzigkeit wrote a gizmo that allowed development and testing of
translators on other OSes. What became of it?
Andrew Archibald
Reply to: