[SCM] Samba Shared Repository - branch master updated

Ira Cooper ira at samba.org
Wed Dec 17 12:31:37 MST 2014

On Wed, Dec 17, 2014 at 11:13 AM, Volker Lendecke <Volker.Lendecke at sernet.de
> wrote:
> Hi, Günther!
> On Wed, Dec 17, 2014 at 04:36:03PM +0100, Günther Deschner wrote:
> > The branch, master has been updated
> >        via  051b81a vfs_glusterfs: Implement AIO support
> >        via  26b3544 vfs_glusterfs: Change sys_get_acl_file/fd to return
> ACLs corresponding to mode bits when there are no ACLs set.
> >       from  770f222 script/autobuild.py: use --picky-developer for the
> samba-ctdb target
> >
> > https://git.samba.org/?p=samba.git;a=shortlog;h=master
> >
> >
> > - Log -----------------------------------------------------------------
> > commit 051b81aac81c7ccb234da221e9f8272b70b265ce
> > Author: Poornima G <pgurusid at redhat.com>
> > Date:   Thu Dec 11 07:35:10 2014 +0530
> >
> >     vfs_glusterfs: Implement AIO support
> Can you describe a bit more about the design of this AIO support? In
> Samba we are trying really, really hard to avoid any thread calls in
> "application level" code. This puts pthread code at a rather high level.
> I could not find any information about how glusterfs does the async I/O,
> but I would be really surprised if it mandates the use of pthreads.
> Maybe you can shed a bit of light on this?


I don't believe there's any real standard on the use of threads in VFS
modules.  In fact there is a vfs_aio_pthread.c module which tends to make
me think that threads ARE allowed at the VFS layer, as long as you don't
expose them to the rest of Samba.

But to your actual question, about Gluster's AIO.  libgfapi, the Gluster
userland interface library,  is threaded and the callback we get can come
in from any thread.  We have no control over that.  The code you see is
code to actually queue the events, and handle them in the main thread,

I can see ways to eliminate the locking and eventfd code, using pipes, but
beyond that, I don't see much we can do here.  The issue there will be
making sure we maintain the performance of the current implementation.



More information about the samba-technical mailing list