> On Oct 29, 2024, at 9:57 AM, Martin Wege <martin.l.wege@xxxxxxxxx> wrote: > > On Wed, Oct 23, 2024 at 5:58 PM Mike Snitzer <snitzer@xxxxxxxxxx> 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
