From: 'J. Bruce Fields' [mailto:bfields@fieldses.org] Sent: Friday, March 8, 2019 1:38 PM To: Frank Filz <ffilzlnx@mindspring.com> Cc: 'linux-fsdevel' <linux-fsdevel@vger.kernel.org>; Volker.Lendecke@sernet.de; samba-technical@lists.samba.org; 'Jeremy Allison' <jra@samba.org>; 'Linux NFS Mailing List' <linux-nfs@vger.kernel.org>; 'Jeff Layton' <jlayton@kernel.org>; 'Amir Goldstein' <amir73il@gmail.com>; devel@lists.nfs-ganesha.org; 'Ralph Boehme' <slow@samba.org> Subject: [NFS-Ganesha-Devel] Re: Better interop for NFS/SMB file share mode/reservation
On Wed, Mar 06, 2019 at 07:37:00AM -0800, Frank Filz wrote:
On Wed, Mar 06, 2019 at 09:09:21AM +0200, Amir Goldstein wrote:
On Tue, Mar 5, 2019 at 11:48 PM J. Bruce Fields <bfields@fieldses.org> 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).
OK. So I wonder about Ganesha. I'm not sure, but I *think* it's like knfsd in that it has a bunch of worker threads that can each take rpc's from any client. I don't remember if they're actually threads or processes.
Ganesha does use worker threads
And they're all part of one process?
Sorry, should have specified, yes, Ganesha runs a single multi-threaded process.
however, one thing that may be an advantage here, or at least can be leveraged, is that Ganesha attaches a single file descriptor to each stateid. As long as the I/O requests come using the stateid, that file descriptor will be used.
We have some work completed and more in progress on delegations, and if there becomes a new kernel oplock available, we could definitely use it. On the other hand, FSAL_VFS which is the FSAL used with kernel file systems does not support delegations...
The (distributed) file systems we support delegations on have use space libraries (which Samba should also be using?) that implement the delegation primitives.
Is there anyone working on delegation support for FSAL_VFS? If it's not getting much attention then maybe Samba is the only real user for the forseeable future.
As far as I know, no one is working on delegations for FSAL_VFS. A good interface would make it something that might be used if it then became easy to implement delegations. FSAL_VFS is convenient for verifying some of the protocol and meta-data caching features of Ganesha. Frank