Re: NFS serving off NTFS panic

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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@xxxxxxxxxxxxx>