Re: [PATCH v3] nfsd: disallow file locking and delegations for NFSv4 reexport

[Chuck Lever III <chuck.lever@oracle.com>]

> On Oct 29, 2024, at 11:54 AM, Brian Cowan <brian.cowan@hcl-software.com> wrote:
> 
> Honestly, I don't know the usecase for re-exporting another server's
> NFS export in the first place. Is this someone trying to share NFS
> through a firewall? I've seen people share remote NFS exports via
> Samba in an attempt to avoid paying their NAS vendor for SMB support.
> (I think it's "standard equipment" now, but 10+ years ago? Not
> always...) But re-exporting another server's NFS exports? Haven't seen
> anyone do that in a while.

The "re-export" case is where there is a central repository
of data and branch offices that access that via a WAN. The
re-export servers cache some of that data locally so that
local clients have a fast persistent cache nearby.

This is also effective in cases where a small cluster of
clients want fast access to a pile of data that is
significantly larger than their own caches. Say, HPC or
animation, where the small cluster is working on a small
portion of the full data set, which is stored on a central
server.


> Using "only local locks for reexport" would mean that -- in cases
> where different clients access the underlying export directly and
> others access the re-export -- you would have 2 different sources of
> "truth" with respect to locks... I have supported multiple tools that
> used file or byte-range record locks in my career... And this could
> easily royally hork any shared databases...

Yes, that's the downside of the local-lock-only approach.

I had assumed that when locking was not available on the NFS
server, the client can mount with "local_lock" (man nfs(5)).


> Regards,
> 
> Brian Cowan
> 
> Regards,
> 
> Brian Cowan
> 
> ClearCase/VersionVault SWAT
> 
> 
> 
> Mob: +1 (978) 907-2334
> 
> 
> 
> hcltechsw.com
> 
> 
> 
> On Tue, Oct 29, 2024 at 10:11 AM Chuck Lever III <chuck.lever@oracle.com> wrote:
>> 
>> 
>> 
>>> On Oct 29, 2024, at 9:57 AM, Martin Wege <martin.l.wege@gmail.com> wrote:
>>> 
>>> On Wed, Oct 23, 2024 at 5:58 PM Mike Snitzer <snitzer@kernel.org> wrote:
>>>> 
>>>> We do not and cannot support file locking with NFS reexport over
>>>> NFSv4.x for the same reason we don't do it for NFSv3: NFS reexport
>>>> server reboot cannot allow clients to recover locks because the source
>>>> NFS server has not rebooted, and so it is not in grace.  Since the
>>>> source NFS server is not in grace, it cannot offer any guarantees that
>>>> the file won't have been changed between the locks getting lost and
>>>> any attempt to recover/reclaim them.  The same applies to delegations
>>>> and any associated locks, so disallow them too.
>>>> 
>>>> Add EXPORT_OP_NOLOCKSUPPORT and exportfs_lock_op_is_unsupported(), set
>>>> EXPORT_OP_NOLOCKSUPPORT in nfs_export_ops and check for it in
>>>> nfsd4_lock(), nfsd4_locku() and nfs4_set_delegation().  Clients are
>>>> not allowed to get file locks or delegations from a reexport server,
>>>> any attempts will fail with operation not supported.
>>> 
>>> Are you aware that this virtually castrates NFSv4 reexport to a point
>>> that it is no longer usable in real life?
>> 
>> "virtually castrates" is pretty nebulous. Please provide a
>> detailed (and less hostile) account of an existing application
>> that works today that no longer works when this patch is
>> applied. Only then can we count this as a regression report.
>> 
>> 
>>> If you really want this,
>>> then the only way forward is to disable and remove NFS reexport
>>> support completely.
>> 
>> "No locking" is already the way NFSv3 re-export works.
>> 
>> At the moment I cannot remember why we chose not to go with
>> the "only local locking for re-export" design instead.
>> 
>> 
>> --
>> Chuck Lever
>> 
>> 

--
Chuck Lever