From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gorcunov@gmail.com>
Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com
 [209.85.208.195])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id D1841469710
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 15 May 2020 12:00:47 +0300 (MSK)
Received: by mail-lj1-f195.google.com with SMTP id w10so1425384ljo.0
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 15 May 2020 02:00:47 -0700 (PDT)
Date: Fri, 15 May 2020 12:00:44 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
Message-ID: <20200515090044.GA2242@grain>
References: <20200421213930.28713-1-gorcunov@gmail.com>
 <20200506170818.xhs2yda3oz6426az@tkn_work_nb>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200506170818.xhs2yda3oz6426az@tkn_work_nb>
Subject: Re: [Tarantool-patches] [PATCH] fio/coio: handle partial writes
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tml <tarantool-patches@dev.tarantool.org>

On Wed, May 06, 2020 at 08:08:18PM +0300, Alexander Turenko wrote:
> > issue https://github.com/tarantool/tarantool/issues/4651
> > branch gorcunov/gh-4651-partial-write
> 
> > diff --git a/src/lib/core/coio_file.c b/src/lib/core/coio_file.c
> > index e2345567c..e290214bc 100644
> > --- a/src/lib/core/coio_file.c
> > +++ b/src/lib/core/coio_file.c
> > @@ -164,10 +164,30 @@ coio_file_close(int fd)
> >  ssize_t
> >  coio_pwrite(int fd, const void *buf, size_t count, off_t offset)
> >  {
> 
> In Febrary ([1]) we start discussing whether the loop should be in fio
> or in coio. coio_p?write() returns amount of written bytes, so it seems
> logical to keep it performing one write and move the loop to
> src/lua/fio.c.
> 
> To be honest, I don't sure here. If you have a reason to keep the logic
> here, please, explain it.

Because lua interface should not dive into low-level coio_ engine, moreover
implementing it at this level we'are allowed to reuse coio_ helpers in
future. In turn if we implement this on fio level we can't reuse it anywhere
outside.

> I'll CC Vlad, maybe he has more strong vision here.
> 
> [1]: https://lists.tarantool.org/pipermail/tarantool-patches/2020-February/014403.html
> 
> > @@ -201,6 +221,11 @@ static void
> >  coio_do_write(eio_req *req)
> >  {
> >  	struct coio_file_task *eio = (struct coio_file_task *)req->data;
> > +
> > +	ERROR_INJECT(ERRINJ_COIO_WRITE_CHUNK, {
> > +		eio->write.count = 1;
> > +	});
> 
> Why not set it right in coio_write() to don't spread the logic?

Because the error should happen as close to native write call
as possible to simulate real behaviour.

So I rebased the patch on latest master and pushed it back.