Re: NFS4 crack

[Peter Staubach <staubach@redhat.com>]

Trond Myklebust wrote:

>to den 22.09.2005 Klokka 13:38 (-0400) skreiv Peter Staubach:
>  
>
>>It seems to me that a "system call" could implemented which would allow
>>a file to be "opened" via the file handle.
>>    
>>
>
>Sure, but open alone isn't sufficient. A lot (most?) of the operations
>involving filehandles are acting on directories.
>
>Imagine if someone renames a directory on the server while the NFS
>server is in the middle of an unlink() operation, for instance.
>

Yup, although you could resolve that by introducing a whole set of
operations which work off of file descriptors, instead of pathnames.
Then, inside of the kernel, to do the real operation, the file
descriptor would get turned back into the inode, but without the
pathname look portion.  Things like funlink(fd, name), fmkdir(fd, name),
frmdir(fd, name), etc.  Other operating systems have implemented at
least a subset of these sorts of calls and it gets ugly quickly.

The NFS server also has to do its own special checking and sometimes
this checking conflicts with the checking done in the normal "from
user mode" path.

---

Without a great deal of work and many new interfaces, there is no way
to get something like the NFS server to run correctly outside of the
kernel address space.  There are correctness issues such as Trond has
pointed out and there are performance issues as well.

Is there inherent problem with the NFS server being implemented as an
alternate VFS layer in the kernel, with its own requirements?  Or is
this an academic problem?  Unless we are willing to consider moving to
a micro-kernel approach, ala Mach, then we are going to need to consider
the requirements of kernel based applications in addition to user level
applications.

    Thanx...

       ps