Re: NFS4 crack

[Nicholas Miell <nmiell@comcast.net>]

On Thu, 2005-09-22 at 14:07 -0400, Peter Staubach wrote:
> 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.

Solaris 10 calls them fchownat(2), fstatat(2), futimesat(2), openat(2),
renameat(2), and unlinkat(2). They mostly exist to support their
extended attributes implementation (hence the "at" postfix, and not to
be confused with Linux's xattrs), but they work for general filesystem
usage.

Besides being an interface to extended attributes and maybe making an
userspace NFSd feasible, they probably also improve filename lookup
performance on sufficiently deep directory heirarchies (think of httpd
opening /var/www/vservers/www.blah.com/html/ and then resolving
everything for that vserver relative to the cached fd).

-- 
Nicholas Miell <nmiell@comcast.net>