From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Fri, 12 Apr 2019 17:53:47 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH] lib/core/coio_file: Use eio_sendfile_sync instead of a
 chunk mode
Message-ID: <20190412145347.sl3m5zynsg5sujg5@esperanza>
References: <20190410193624.12510-1-gorcunov@gmail.com>
 <20190412134323.ebqjjxaqgpbu4dt5@esperanza>
 <20190412140558.GB20557@uranus>
 <20190412141916.janpwwy27epsfbfv@esperanza>
 <20190412144212.GC20557@uranus>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190412144212.GC20557@uranus>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@freelists.org>
List-ID: <tarantool-patches.dev.tarantool.org>

On Fri, Apr 12, 2019 at 05:42:12PM +0300, Cyrill Gorcunov wrote:
> On Fri, Apr 12, 2019 at 05:19:16PM +0300, Vladimir Davydov wrote:
> ...
> > > But I agree that using sendfile here actually may trim file. I'll take
> > > a look at evening but I think we should rather use sendfile with offsets
> > > in a cycle. Seriouly, using 4K buffer is the worst possible algo :)
> > 
> > Yeah, it would be great to make use of sendfile, but we must make sure
> > we won't occasionally break anything.
> 
> I will have to update tests. The problem only is that we've to test
> big files here, have no clue if our CI engine will allow us to
> generate/copy such sizes.

True, I don't think it's worth testing it.

I just wanted to say that we need to make sure it works - check it
manually and I will too.

Alternatively, we could add an error injection, reducing the sendfile
copy size, but I think it's not really necessary.