On Tue, Mar 5, 2019 at 11:48 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Thu, Feb 14, 2019 at 04:06:52PM -0500, J. Bruce Fields wrote: > > After this: > > > > https://marc.info/?l=linux-nfs&m=154966239918297&w=2 > > > > delegations would no longer conflict with opens from the same tgid. So > > if your threads all run in the same process and you're willing to manage > > conflicts among your own clients, that should still allow you to do > > multiple opens of the same file without giving up your lease/delegation. > > > > I'd be curious to know whether that works with Samba's design. > > Any idea whether that would work? > > (Easy? Impossible? Possible, but realistically the changes required to > Samba would be painful enough that it'd be unlikely to get done?) > [CC Ralph Boehme] I am not a samba team member, but seems to me that your proposal fits samba design like a glove. With one smbd process per client connection, with your proposal, opens (for read) from same smbd process will not break the shared read lease from same client, so oplocks level II could be implemented using kernel oplocks (new flavor). IOW, can someone from samba team please elaborate on this quote from samba wiki [1]: "Linux kernel oplocks don't provide the needed features. (They don't even work correctly for oplocks...) ==> SMB-only feature." [1] https://wiki.samba.org/index.php/Samba3/SMB2#new_concepts I would like to use this opportunity to ask samba team members to raise any (*) other pain points about missing or lacking Linux kernel interfaces. I promise to use my time in LSF/MM 2019 to try and promote samba needs among Linux filesystem developers. Preferably, update the samba wiki page with wish list from Linux kernel, but try to be more descriptive than "... don't provide the needed features". (*) OK, not RichACLs. I know my own limitations. Thanks, Amir.
