Hi Bruce, I have been following you discussion with Volker Lendecke on the samba technical mailing list [1] and have had discussed this issue with Volker myself as well. I decided to start this new thread to bring some kernel developers in the loop and to propose an idea that takes a somewhat different approach to the "interop" approaches I have seen so far. "interop" in this context often means consistency of file lock states between samba and nfs server, but I am referring to the stronger sense of interop with local filesystem on the server. You pointed to Pavel Shilovsky's O_DENY* patches [2] as a possible solution to interop of NFS Share Reservation and SMB Share Mode with local filesystems. Some of the complaints on this approach were (rightfully) concerned about DoS and the prospect of plaguing Linux with Windows server "files left open" issues. My idea comes from the observation that Windows server administrators can release locked files that were left open by clients. I suppose that an NFS server admin can do the same? That realization makes "share access" locks (a.k.a. MAND_LOCK) not so very different from oplocks (leases/delegations). As long as samba and nfsd cooperate nicely with MAND_LOCK semantics, we don't really have to force local filesystems to obay MAND_LOCK semantics. If the file servers take leases on local filesystems, they will not get exclusive write access for files already open for write on local filesytem and same for read. On local file access on the server that violates the share mode, the file server acts as a grumpy washed out administrator that automatically grants any lock revoke ticket after timeout. This model may not fit use cases where "real" interop with local filesystem is needed, but compared to the existing solution (no interop at all) it is quite an improvement. Furthermore, short of SMB DENY_DELETE, we may not even need to change any kernel APIs. The addition of O_DENY* open flags can make programming easier, but taking a lease on an open file is still safe enough to implement share reservation (no?). Satisfying DENY_DELETE could be more tricky, but perhaps the existing SILLYRENAME interface of==between knfsd and vfs could be somehow utilized for this purpose? I though of bringing this up as a TOPIC for LSF/MM, but wanted to consult with you first. I am sure that you or Jeff can do a better job than me in enumerating the "interop" file lock issues that could be discussed in filesystems track forum. Thoughts? Explanation why this idea is idiotic? Thanks, Amir. [1] https://lists.samba.org/archive/samba-technical/2019-February/132366.html [2] https://lore.kernel.org/lkml/1389953232-9428-1-git-send-email-piastry@xxxxxxxxxxx/
