[email protected] wrote on 10/26/2013 06:20:12 AM:
> I'd rather look bad for not supporting a broken filesystem feature
> than have to deal with the abiove mentioned side-effects. Until the
> xattr interface is properly documented and standardised so that it
> can be exported safely, it should be treated as a unexportable, in
> the same way we treat procfs and sysfs.
>
This sounds more like an NFS server problem than a client side NFS. Can we
add support to the client side NFS and let server that think that they can
handle XATTR implement it?
We should probably start a discussion in the IETF to resolve the issues
you see with XATTR at least for NFSv4.3.
Marc.
> Cheers
> Trond--
On Sun, 27 Oct 2013, Myklebust, Trond wrote:
> > This sounds more like an NFS server problem than a client side NFS. Can we
> > add support to the client side NFS and let server that think that they can
> > handle XATTR implement it?
>
> No. It's a real problem for clients too if the NFS server starts
> exporting ACLs and security labels via this interface. Everything from
> integer endianness problems when getfacl attempts to read raw binary
> acls from the server, to breakage of caching models when we allow
> setfacl and don't invalidate our file access caches...
Right, so any general xattrs for nfs would need to be specified as having
no system effects, essentially exporting the Linux 'user' xattr namespace
only.
>
> > We should probably start a discussion in the IETF to resolve the issues
> > you see with XATTR at least for NFSv4.3.
>
> Let's get the basic discussion of motivation right first.
It should be for user-managed metadata only.
--
James Morris
<[email protected]>
On 10/28/2013 09:25 AM, James Morris wrote:
> On Sun, 27 Oct 2013, Myklebust, Trond wrote:
>
>>> This sounds more like an NFS server problem than a client side NFS. Can we
>>> add support to the client side NFS and let server that think that they can
>>> handle XATTR implement it?
>> No. It's a real problem for clients too if the NFS server starts
>> exporting ACLs and security labels via this interface. Everything from
>> integer endianness problems when getfacl attempts to read raw binary
>> acls from the server, to breakage of caching models when we allow
>> setfacl and don't invalidate our file access caches...
> Right, so any general xattrs for nfs would need to be specified as having
> no system effects, essentially exporting the Linux 'user' xattr namespace
> only.
>
>
>>> We should probably start a discussion in the IETF to resolve the issues
>>> you see with XATTR at least for NFSv4.3.
>> Let's get the basic discussion of motivation right first.
> It should be for user-managed metadata only.
>
That would be what I would like to see over NFS...
ric
On Oct 26, 2013, at 1:46 PM, Marc Eshel <[email protected]> wrote:
> [email protected] wrote on 10/26/2013 06:20:12 AM:
>
>> I'd rather look bad for not supporting a broken filesystem feature
>> than have to deal with the abiove mentioned side-effects. Until the
>> xattr interface is properly documented and standardised so that it
>> can be exported safely, it should be treated as a unexportable, in
>> the same way we treat procfs and sysfs.
>>
>
> This sounds more like an NFS server problem than a client side NFS. Can we
> add support to the client side NFS and let server that think that they can
> handle XATTR implement it?
No. It's a real problem for clients too if the NFS server starts exporting ACLs and security labels via this interface. Everything from integer endianness problems when getfacl attempts to read raw binary acls from the server, to breakage of caching models when we allow setfacl and don't invalidate our file access caches...
> We should probably start a discussion in the IETF to resolve the issues
> you see with XATTR at least for NFSv4.3.
Let's get the basic discussion of motivation right first.
Trond