[Samba] Why samba only use single thread to process request？ Why vfs_cephfs

[John Mulligan]

On Friday, December 3, 2021 12:47:08 PM EST Jeremy Allison via samba wrote:
> On Fri, Dec 03, 2021 at 04:50:50PM +0800, lushasha08--- via samba wrote:
> >Hi, Lists
> >
> >        I recently begin to study samba source code. I am focus on samba
> >        FileServer code.  I have some confusion. Can you give me some
> >        help?>       
> >       1. Why samba only use single thread to process request from one
> >       connection? Why not use threadpools?  I think using threadpool can
> >       improve performance extremly.
> Samba is 30 years old. Portable, working threads were
> merely a fantasy at that time :-).
> 
> Samba is moving towards moving threads in places
> where it makes sense - check out the use of
> lib/pthreadpool/pthreadpool.c in Samba, but
> in many cases (not all of course) the same
> benefits can be gained by using an async
> event model - look at lib/tevent in the
> Samba source code.
> 
> >        2. Why async ceph write faked up by calling the sync API?  Can
> >        async ceph write just use conn's threadpool like glusterfs?
> Ceph needs async primitives, as gluster
> already has. I'm not a ceph expert so
> can't say if it has them but they aren't
> suiitable yet.

This piqued my curiosity as I have a passing familiarity with the cephfs api 
and have done some work with both gluster and ceph. I skimmed the vfs module 
sources and it appears to me that the vfs module for gluster does not directly 
use async calls from libfgapi. Rather, it uses a threadpool to mimic async 
behavior, which is something lushasha08 implied [1].


So, please correct me if I'm wrong, but I think the vfs ceph module could use 
a similar technique if someone was to implement the changes [2]. That said, 
Jeremy's suggestion that the api for cephfs could updated to include async 
functions would probably be even better.


The cephfs API has two sets of function call, a "high level" api that mimics 
many of the traditional unix/posix calls and a "low level" api that operates 
on specialized structs rather than virtual file handles.  However, I don't see 
anything that looks like an async call even in the low level set of calls 
today. I am aware that the api is continuing to evolve as ceph "pacific" now 
makes an "openat" style call available [3]. So perhaps the cephfs maintainers 
would be open to having async apis too.


[1] - https://git.samba.org/?p=samba.git;a=blob;f=source3/modules/
vfs_glusterfs.c;h=25b82bdd4719c7b02a4513d94ca0230dec353540;hb=HEAD#l909

[2] - I'm not volunteering anyone. :-)

[2] - https://github.com/ceph/ceph/blob/pacific/src/include/cephfs/
libcephfs.h#L1180