Extended attributes over NFSv3

[Greg Banks]

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.

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.

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
The cake is *not* a lie.
I don't speak for SGI.