I was just wondering why the Linux NFS server is implemented in the kernel as opposed to a userspace application?

I know a userspace NFS daemon exists, but it's not the standard method for providing NFS server services.

I would think that running NFS server as a userspace application would be the preferred approach as it can provide added security having a daemon run in userspace instead of the kernel. It also would fit with the common Linux principal of doing one thing and doing it well (and that daemons shouldn't be a job for the kernel).
In fact the only benefit I can think of running in the kernel would a performance boost from context switching (and that is a debatable reason).

So is there any documented reason why it is implemented the way it is? I tried googling around but couldn't find anything.

There seems to be a lot of confusion, please note I am not asking about mounting filesystems, I am asking about providing the server side of a network filesystem. There is a very distinct difference. Mounting a filesystem locally requires support for the filesystem in the kernel, providing it does not (eg samba or unfs3).

  • NFS is a filesystem. Userspace filesystem drivers have to use FUSE, which is typically poor for performance. – jordanm Aug 20 '12 at 14:41
  • 1
    you are right, my statement would only apply to the client. – jordanm Aug 20 '12 at 14:49
  • 1
    @StarNamer because ext2/3/4 aren't network filesystems, they're local filesystems. And for a filesystem to be mounted on the local, it either has to be in the kernel, or implemented via FUSE (which has already been discussed) :-) – phemmer Aug 20 '12 at 15:16
  • 1
    @StarNamer That only applies to local file systems. Providing network file systems does not have to be done in the kernel. Samba doesn't run in the kernel :-) – phemmer Aug 20 '12 at 15:17
  • 2
    @StarNamer you're still talking about the client. I'm talking about the server. You can run unfs3 (which is an NFS server) without any kernel support for it. – phemmer Aug 20 '12 at 16:08

unfs3 is dead as far as I know; Ganesha is the most active userspace NFS server project right now, though it is not completely mature.

Although it serves different protocols, Samba is an example of a successful file server that operates in userspace.

I haven't seen a recent performance comparison.

Some other issues:

  • Ordinary applications look files up by pathname, but nfsd needs to be able to look them up by filehandle. This is tricky and requires support from the filesystem (and not all filesystems can support it). In the past it was not possible to do this from userspace, but more recent kernels have added name_to_handle_at(2) and open_by_handle_at(2) system calls.
  • I seem to recall blocking file-locking calls being a problem; I'm not sure how userspace servers handle them these days. (Do you tie up a server thread waiting on the lock, or do you poll?)
  • Newer file system semantics (change attributes, delegations, share locks) may be implemented more easily in kernel first (in theory--they mostly haven't been yet).
  • You don't want to have to check permissions, quotas, etc., by hand--instead you want to change your uid and rely on the common kernel vfs code to do that. And Linux has a system call (setfsuid(2)) that should do that. For reasons I forget, I think that's proved more complicated to use in servers than it should be.

In general, a kernel server's strengths are closer integration with the vfs and the exported filesystem. We can make up for that by providing more kernel interfaces (such as the filehandle system calls), but that's not easy. On the other hand, some of the filesystems people want to export these days (like gluster) actually live mainly in userspace. Those can be exported by the kernel nfsd using FUSE--but again extensions to the FUSE interfaces may be required for newer features, and there may be performance issues.

Short version: good question!

  • 3
    Readers should note that Bruce is (a? the?) maintainer of the linux NFS server, so presumably he knows what he is talking about. :) – Dan Pritts Nov 12 '14 at 18:29
  • @derfian FYI -- you may want to comment here to the effect that "unfs3 is alive and moving to Github" ? – ms-ati May 9 '18 at 15:46
  • I commented the above because @derfian, or StackOverflow user (unix.stackexchange.com/users/23034/derfian), is the maintainer of unfs3, and recently announced it was not dead, for example in this Github comment – ms-ati May 9 '18 at 15:48
  • 1
    For written by an NFS maintainer, this answer is pretty vague. – Torsten Bronger Aug 27 '18 at 20:49
  • 1
    For 2020 readers: This answer is 8 years old, and some things start to rot in this answer. – Dark_eye Dec 26 '19 at 14:04

Olaf Kirch originally developed both the user space and kernel based version of the NFS server. In his year 2000 book, "Linux Network Administration" he says:

The 2.2.0 kernel supports an experimental kernel-based NFS server developed by Olaf Kirch and further developed by H.J. Lu, G. Allan Morris, and Trond Myklebust. The kernel-based NFS support provides a significant boost in server performance.

I think that once the NFS server got moved into the kernel to improve performance, no-one saw any reason to take it out again.


Starnamer is correct (I was one of the beta testers).

Putting it in the kernel was an attempt to improve abysmal performance (mainly to PCNFS clients) and once that issue was solved noone looked at it much again.

There are a number of deficiencies with having NFS in the kernel, not least of which is that it doesn't play nicely with anything else touching the same filesystem (there are seriously nasty corruption risks) but back then (1993-4) we didn't realise that it would turn out to be an issue.

We were younger and more foolish, etc etc.


Section 3 of these slides discuss kernel-space vs user-space NFS-Server implementations. This presentation favours for the user-space implementation of the NFS server (which NFS-Ganesha does)

On the other hand, there is a in-depth deep dive blog post here showing way kernel-space implementation is much faster.

So why kernel-space: A short answer would be better performance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.