On Thu, Aug 23, 2018 at 12:41:49PM -0700, Paul B. Henson wrote: > On 8/23/2018 7:38 AM, J. Bruce Fields wrote: > > >>Does something specifically need to be done individually for each > >>file system, or if it supports the standard extended attribute does > >>any file system (including an out of tree file system) > >>automatically function? > > > >Nothing special's required, it should be automatic. > > So if, hypothetically, the NFSv4 server was enhanced to look for and > understand the standard linux system.nfs4_acl extended attribute, > any file system, whether in kernel or out of tree, would support > exposing NFSv4 ACLs via NFS? Even though there's nothing ZFS > specific about it, that general functionality would not be > acceptable for inclusion in the mainstream kernel? Right, it's against kernel policy, and even if it weren't, I don't want to be in the position of maintaining code, even simple code, that's really only needed for third-party modules without any path to upstream. > That seems a bit of a chicken and egg problem, do you add a feature > for a subsystem to use so said subsystem could be updated to use it, > or you update a subsystem to use a feature that doesn't exist yet > :)? Honestly the system.nfs4_acl extended attribute interface, which just exposes the raw xdr of the ACL to userspace, is kind of a kludge. It could be made to work for other filesystems but I was hoping that other filesystems would adopt something designed for them from scratch (like richacls). That said, there *is* already an in-kernel filesystem that supports system.nfs4_acl: knfsd does actually allow limited re-export of NFS. So knfsd code that used system.nfs4_acl when available might actually have some use, I don't really know. I'm a little skeptical of the idea, to be honest. --b.
