[SCM] Samba Shared Repository - branch master updated

[Poornima Gurusiddaiah]

----- Original Message -----
> From: "Michael Adam" <obnox at samba.org>
> To: "Volker Lendecke" <Volker.Lendecke at SerNet.DE>
> Cc: samba-technical at lists.samba.org
> Sent: Thursday, December 18, 2014 5:52:31 PM
> Subject: Re: [SCM] Samba Shared Repository - branch master updated
> 
> Hi Volker,
> 
> first of all, thanks for your comments and please
> excuse the irritation. The patch seems to have been
> pushed prematurely. Currently an additional patch is
> being worked on and tested which removes all the
> pthread and eventfd calls and replaces the notification
> mechanism by a simple pipe, as Ira has indicated.
> 
> That will remove the immediate concerns about pthread
> calls being used in the module, but still the
> calls to glfs_pread_async() are there, so the more sublte
> concern remains how the gluster gfapi library uses threads
> (and whether it can be avoided). I am currently looking
> into the code, trying to understand it, but I'm sure we
> will also get an update and information from Poornima,
> the patch author.
> 
Glusterfs is a multithreaded application. glfs_pread_async() doesn't really
create any more threads as compared to glfs_pread() api(which is the sync api).
By default when a connection to libgfapi is established (glfs_init()) there will
be 4 threads created, and will increase as the load increases. Out of four, we have
one queuing thread(which will grow) and one poller thread which receives the
acknowledgments from server.

> Stay tuned and thanks - Michael
> 
> On 2014-12-18 at 12:56 +0100, Volker Lendecke wrote:
> > On Wed, Dec 17, 2014 at 04:36:03PM +0100, Günther Deschner wrote:
> > > +	/*
> > > +	 * Store the reqs that needs to be completed by calling
> > > +	 * tevent_req_done(). tevent_req_done() cannot be called
> > > +	 * here, as it is not designed to be executed in the
> > > +	 * multithread environment, tevent_req_done() should be
> > > +	 * executed from the smbd main thread.
> > > +	 */
> > > +	pthread_mutex_lock (&lock_req_list);
> > > +	{
> > > +		for (i = 0 ; i < aio_pending_size ; i++) {
> > > +			if(!req_producer_list[i]) {
> > > +				req_producer_list[i] = req;
> > > +				req_counter = req_counter + 1;
> > > +				break;
> > > +			}
> > > +		}
> > > +	}
> > > +	pthread_mutex_unlock (&lock_req_list);
> > 
> > One thing that just struck me (and that it took so long to
> > figure this out is a bad sign to me): Wherever there's a
> > pthread_mutex_lock call there needs to be the corresponding
> > pthread_atfork handler. smbd expects to be able to fork
> > properly, I know of an internal VFS module that does this.
> > And we have a module vfs_aio_fork that might be applied to
> > a different share. So we need to maintain forkability. With
> > the phreadpool approach I've tried to take care of this (if
> > that's not complete, please tell me!).
> > 
> > As I've not found documentation about the gluster aio
> > interface, can we get confirmation from the developers of
> > the gluster library that this is being taken care of?
> > 
> > Thanks!
> > 
> > Volker
> > 
> > --
> > SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> > phone: +49-551-370000-0, fax: +49-551-370000-9
> > AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> > http://www.sernet.de, mailto:kontakt at sernet.de
>