Re: [RFC PATCH v2 00/11] NFS/NFSD: nfs4_acl passthru for NFSv4 reexport

Chuck Lever
2026-03-10T16:42:41Z

On Tue, Mar 10, 2026, at 10:58 AM, Christoph Hellwig wrote:
> On Tue, Mar 10, 2026 at 10:53:56AM -0400, Trond Myklebust wrote:
>> If the upstream community is unwilling to take patches to address the
>> issue, then we're quite happy to maintain the code separately. It will
>> still be available to those who need it through our github site.
>
> For something so special purpose I think that is the better way.

My experience is that Hammerspace is not the only consumer of
NFSv4 re-export, so I regard the issue as a shortcoming of the
current NFSD NFSv4 ACL implementation that will have broader
impact than one storage vendor. Thus I feel that having Hammerspace
maintain this feature separately will in the end not be good for
the community -- it should be merged upstream if it can be.

Even so, NFS re-export itself is not a commonly used feature. It
would be helpful to construct ACL bypass so that some or much of
it can be tested in common configurations. Then it can benefit
from commodity testing experience, rather than languishing as a
niche feature. This is why I encouraged the implementation of
FATR4_DACL and FATTR4_SACL as full-fledged features rather than
specifically and only for NFS re-export. That enables the
construction of pynfs and other unit tests that can be deployed
in CI without having to set up a re-export scenario.

Where I have trouble generally with Hammerspace's contributions
is that they do tend towards the niche, and frequently they are
presented here without consideration for how the community will
test, support, and maintain them in the long run. The proposed
features are often complex and they will have real ongoing costs
for us.

Food for discussion.

--
Chuck Lever