Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Cyrill Gorcunov <gorcunov@gmail.com>,
	Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tml <tarantool-patches@dev.tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH] fio/coio: handle partial writes
Date: Wed, 10 Jun 2020 00:55:06 +0200	[thread overview]
Message-ID: <5ccb1c92-77f8-d875-0472-c6cb66680a41@tarantool.org> (raw)
In-Reply-To: <20200515090044.GA2242@grain>

On 15/05/2020 11:00, Cyrill Gorcunov wrote:
> 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.

Talking of lua diving into low-level things - our Lua C API is supposed to
work with low-level things, to wrap them, and provide easier to use Lua API.
So for flexibility purposes there are no any obstacles to move IO-retry
cycles into lua/ and box/lua where needed. To keep the low-level API low-level.

When you move retries into the lowest possible API, it becomes impossible
to let partial writes handling to other code. If such would appear in future.

Probably the best compromise would be to keep the old calls as is in coio,
but add new methods like coio_write_all(), coio_read_all(), etc. Which would
retry, and would be used by Lua C API.

I am ok with any option, including the current patch. I just don't agree, that
it is the only true way.

> In turn if we implement this on fio level we can't reuse it anywhere
> outside.

On the other hand, when partial writes don't exist, we can't get them
when need.

  parent reply	other threads:[~2020-06-09 22:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21 21:39 Cyrill Gorcunov
2020-05-06 17:08 ` Alexander Turenko
2020-05-15  9:00   ` Cyrill Gorcunov
2020-06-09 16:55     ` Alexander Turenko
2020-06-09 22:55     ` Vladislav Shpilevoy [this message]
2020-06-09 22:55 ` Vladislav Shpilevoy
2020-06-10  7:52   ` Cyrill Gorcunov
2020-06-11 19:36     ` Vladislav Shpilevoy
2020-06-11 19:43       ` Cyrill Gorcunov
2020-06-11 19:56         ` Vladislav Shpilevoy
2020-06-11 20:12           ` Cyrill Gorcunov
2020-06-11 19:56 ` Vladislav Shpilevoy
  -- strict thread matches above, loose matches on Subject: below --
2019-11-26 18:05 [Tarantool-patches] [PATCH] fio/coio: Handle " Cyrill Gorcunov
2019-12-04  9:44 ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ccb1c92-77f8-d875-0472-c6cb66680a41@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=gorcunov@gmail.com \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] fio/coio: handle partial writes' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox