On Mon, 4 Feb 2008, Jeff Garzik wrote: > > Well, speaking as a complete nutter who just finished the bare bones of an > NFSv4 userland server[1]... it depends on your approach. You definitely are a complete nutter ;) > If the userland server is the _only_ one accessing the data[2] -- i.e. the > database server model where ls(1) shows a couple multi-gigabyte files or a raw > partition -- then it's easy to get all the semantics right, including file > handles. You're not racing with local kernel fileserving. 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 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
