On Oct 26, 2013, at 1:46 PM, Marc Eshel <eshel@xxxxxxxxxx> wrote: > linux-nfs-owner@xxxxxxxxxxxxxxx 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-- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
