:I mean that, if it works fine locally but not as an NFS export,
:something is being overcomplicated; maybe for a good reason but this is
:still a problem overall. A userland NFS would fix this, or a
:sufficiently simple kernel NFS (too late now).
I wish it were that easy. The problem is that NFS is accessing
elements of the VFS that a local mount does not. In particular,
NFS needs to have some understanding of a 'file handle' which in turn
means that NFS has to be able to take a file handle identifier and
convert it to a vnode. Local mounts do not have to do deal with such
conversions. NFS also has to reformat directories from whatever the
VFS uses to a common standard over the wire. These elements make
the NFS server a bit more complex.
:Is it DragonFly's goal to move anything sensible into the userland where
:possible? I've seen this mind share among a few of the other developers.
:It makes a lot of sense for serving tasks like NFS, but I've had
:mentioned that it should also handle some low-overhead tasks the kernel
:has to do even for devices (moused, for instance). Where is the line drawn?
:
:Dmitri Nikulin
NFS is perhaps a bad example. It is my intention to eventually allow
any VFS to be run in userland OR the kernel, but on a production system
the method one chooses will be highly dependant on that person's
efficiency and stability requirements. e.g. running NFS in userland
would save the kernel from an NFS-related crash, but it would also make
NFS rather inefficient. So its a trade-off.
-Matt
Matthew Dillon
<dillon@backplane.com>