[PATCH#3] fake data io module for samba
Volker.Lendecke at SerNet.DE
Mon Dec 29 01:11:36 MST 2014
On Mon, Dec 29, 2014 at 12:42:28AM +0100, Peter Somogyi wrote:
> Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote on 12/27/2014 12:44:48
> > On Fri, Dec 26, 2014 at 12:41:32PM -0700, Christof Schmitt wrote:
> > > Having a user explicitly set "fake_io:destroy data" to "yes", should
> > > a sufficient warning.
> > Sounds good.
> Ok adding it on ToDo.
> > > For shares with async i/o enabled, you probably also need to intercept
> > > async calls (pread_send, pwrite_send).
> I did not intend to support aio as I had concern being asys_pread_do not
> on the VFS:
> ret = pthreadpool_add_job(ctx->pool, jobid, asys_pread_do, job);
> Maybe let me chose code duplication (although I fear of future breakage),
> seeing the VFS addition harder achieve.
> > Yep. One thing this module could test would be some
> > arbitrary or random delay in the async pread/pwrite
> > operations in order to test the for example our client-side
> > crediting algorithm. If we hold back some requests
> > server-side, the client should fill the pipe according to
> > the available credits and continue when they become
> > available.
> > Volker
> Volker, did you mean adding the delay to the beginning of the whole
> vfswrap_pread_recv/send, or just the async parts
> [asys_pread_do/asys_pwrite_do] (which are not on the VFS) ?
> I assume vfswrap_pread_recv/send VFS calls were designed to return
Yes, the _send calls are designed to return immediately
without any delay or blocking. You could pretty easily add a
tevent_wakeup_send to the pread_send call to wake you up
after a read delay. This way many outstanding request would
be handled in parallel with some random timeout.
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
More information about the samba-technical