Re: [PATCH 3/8][RFC v05] NFSv3: add client implementation of XATTR protocol

[Casey Schaufler <casey@schaufler-ca.com>]

Chuck Lever wrote:
> Hi James-
>
> Good points, see below.
>
> On 06/22/10 08:26 PM, James Morris wrote:
>> On Tue, 22 Jun 2010, Chuck Lever wrote:
>>
>>> Another place to look is at NFSv4.  Some of the operations that can be
>>> performed on NFSv4 xattrs are probably nearly what you would want
>>> for an NFSv3
>>> implementation.  I think it is desirable for anything done for NFSv3
>>> to be
>>> compatible with NFSv4, as that is already a standard.
>>
>> Are you referring to named attributes?  I've looked into this, as have
>> others, and they appear to be fundamentally incompatible with Linux/BSD
>> xattrs.  They're filesystems within files, with different semantics
>> to the
>> name/value string model that we use.  I've heard a few developers say
>> they've looked at implementing xattrs over NAs, but found it unworkable.
>>
>> There's the issue of namespacing -- named attributes have no structured
>> namespace, whereas, Linux/BSD xattrs use namespaces to denote semantics.
>>
>> NAs are also intended to be managed at the user level without kernel
>> interaction, which conflicts with the semantics of our system
>> namespaces.
>>
>> In the past, I've seen several discussions on the issue conclude that
>> NFSv4 should have distinct Linux/BSD xattr OPs, although I don't know
>> what
>> the current thinking is.
>
> My thought was to extend NFSv4 to provide native xattr support
> alongside named attribute support.  If NFSv4 is getting security label
> support then that's a moot point, unless there are other use cases for
> exposing xattrs to NFS clients.
>
> Overall, I think everyone is better off in the long run if we get the
> needed features into NFSv4.

Agreed, but we're talking years before that happens. Work on labeled
NFS has been ongoing since 1985 and there is no reason to believe that
NFSv4 is going to progress at a quicker pace than any of its predecessors.