> On Oct 29, 2024, at 11:54 AM, Brian Cowan <brian.cowan@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote: >> >> >> >>> 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 >> >> -- Chuck Lever
