[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/
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
More information about the samba
mailing list