[Samba] Why samba only use single thread to processrequest? Why vfs_cephfs

lushasha08 at 126.com lushasha08 at 126.com
Mon Dec 6 02:56:28 UTC 2021

Thanks for your early reply.

Jeremy's reply give me a lot help. 

 I agree with John,  vfs_ceph can uses a threadpool to mimic async behavior just like vfs_gluster before ceph support async apis.

From: John Mulligan
Date: 2021-12-04 23:42
To: samba
CC: lushasha08 at 126.com; Jeremy Allison
Subject: Re: [Samba] Why samba only use single thread to processrequest? Why vfs_cephfs
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/
[2] - I'm not volunteering anyone. :-)
[2] - https://github.com/ceph/ceph/blob/pacific/src/include/cephfs/

More information about the samba mailing list