Cc: J. Bruce Fields <bfields@...>, Nicholas A. Bellinger <nab@...>, James Bottomley <James.Bottomley@...>, Vladislav Bolkhovitin <vst@...>, Bart Van Assche <bart.vanassche@...>, Andrew Morton <akpm@...>, FUJITA Tomonori <fujita.tomonori@...>, <linux-scsi@...>, <scst-devel@...>, Linux Kernel Mailing List <linux-kernel@...>, Mike Christie <michaelc@...>
You definitely are a complete nutter ;)
It's not really simple in general even then. The problems come with file
handles, and two big issues in particular:
- handling a reboot (of the server) without impacting the client really
does need a "look up by file handle" operation (which you can do by
logging the pathname to filehandle translation, but it certainly gets
problematic).
- non-Unix-like filesystems don't necessarily have a stable "st_ino"
field (ie it may change over a rename or have no meaning what-so-ever,
things like that), and that makes trying to generate a filehandle
really interesting for them.
I do agree that it's possible - we obviously _did_ have a user-level NFSD
for a long while, after all - but it's quite painful if you want to handle
things well. Only allowing access through the NFSD certainly helps a lot,
but still doesn't make it quite as trivial as you claim ;)
Of course, I think you can make NFSv4 to use volatile filehandles instead
of the traditional long-lived ones, and that really should avoid almost
all of the problems with doing a NFSv4 server in user space. However, I'd
expect there to be clients that don't do the whole volatile thing, or
support the file handle becoming stale only at certain well-defined points
(ie after renames, not at random reboot times).
Linus
--
