[Tarantool-patches] [PATCH] fio/coio: handle partial writes

[Vladislav Shpilevoy]

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.