From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 3DB62469711 for ; Wed, 10 Jun 2020 01:55:09 +0300 (MSK) References: <20200421213930.28713-1-gorcunov@gmail.com> <20200506170818.xhs2yda3oz6426az@tkn_work_nb> <20200515090044.GA2242@grain> From: Vladislav Shpilevoy Message-ID: <5ccb1c92-77f8-d875-0472-c6cb66680a41@tarantool.org> Date: Wed, 10 Jun 2020 00:55:06 +0200 MIME-Version: 1.0 In-Reply-To: <20200515090044.GA2242@grain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH] fio/coio: handle partial writes List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cyrill Gorcunov , Alexander Turenko Cc: tml 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.