Extended attributes over NFSv3

[J. Bruce Fields]

On Thu, Jul 24, 2008 at 08:23:17AM +1000, Greg Banks wrote:
> J. Bruce Fields wrote:
> > On Thu, Jul 24, 2008 at 04:24:20AM +1000, James Morris wrote:
> >   
> >> On Wed, 23 Jul 2008, Christoph Hellwig wrote:
> >>
> >>     
> >>> SGI has a side band protocol for extended attributes over NFSv3 and even
> >>> released sample code a few years ago.  If someone cares enough this
> >>> would be about two man month to implement it.
> >>>       
> >> Is it possible to get that accepted into the kernel given that it will be 
> >> non-standard ?
> >>     
> >
> > It'd be fine by me; I don't know about Trond.
> >
> > NFSv4 seems harder; in theory it's very extensible, but in practice I'm
> > not sure how you'd make a private extension without risk of colliding
> > with a later standard.  And you could update the SGI protocol for v4 and
> > use a separate program as with v2/v3, but the lack of sideband protocols
> > has been one of the requirements for v4....
> >
> >   
> I've tried implementing xattrs for Linux' NFSv4 using the existing NFSv4
> named attributes protocol feature, which is the obvious candidate for
> how to do this.
> 
> Unfortunately the mapping between xattr semantics and named attrs is
> rather painful.
> 
> The RFC assumes (and I've checked this interpretation with Mike Eisler)
> that two new magical types of persistent file handle can be constructed,
> i.e. file handles that can be saved and re-used in a later call as
> opposed to a filehandle that is only used by later operations within the
> same call.  One type would be for the "named attribute directory" of a
> regular file, and one type would be for the named attributes within that
> directory.  These are kind of hard to do with the Linux VFS xattr interface.
> 
> Another problem is that NFSv4 requires (assuming the same
> interpretation) the server to be able to handle reads and writes to
> subsets of the xattr data, which the VFS interface doesn't support
> either, so there's a certain amount of painful glue needed to make the
> two go together.

Yes, I went through the same exercise, and I think one or two other
people may have too.

> I think it would be relatively easy to implement xattrs between Linux
> machines if one ignored the RFC thus:
> 
> a) the directory file handle returned from the OPENATTR operation only
> lasts until the end of the current call and cannot be used in a GETFH
> operation.
> b) ditto the file handle returned from LOOKUP on the directory file
> handle from OPENATTR
> c) READDIR on the directory file handle  from OPENATTR never returns the
> file_handle attribute of entries
> d) READ on a named attr file handle only works when the offset is zero
> and the length is at least as long as the xattr
> e) WRITE on a named attr file handle only works when the offset is zero,
> and has the otherwise surprising side effect of truncating the "file" to
> the size of the WRITE.
> 
> But this probably would not interoperate very well with Solaris' named
> attrs.

Right.  My impression was that they are real first-class inodes that
happen to be looked up in a strange way.

Our concensus therefore has been that "extended attributes" and "named
attributes" are fundamentally different objects that need different
protocol.

--b.