From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Fri, 12 Apr 2019 17:05:58 +0300 From: Cyrill Gorcunov Subject: Re: [PATCH] lib/core/coio_file: Use eio_sendfile_sync instead of a chunk mode Message-ID: <20190412140558.GB20557@uranus> References: <20190410193624.12510-1-gorcunov@gmail.com> <20190412134323.ebqjjxaqgpbu4dt5@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190412134323.ebqjjxaqgpbu4dt5@esperanza> To: Vladimir Davydov Cc: tml List-ID: On Fri, Apr 12, 2019 at 04:43:23PM +0300, Vladimir Davydov wrote: > > + ssize_t nwritten = eio_sendfile_sync(dest_fd, source_fd, 0, st.st_size); > > + if (nwritten != st.st_size) { > > + say_syserror("sendfile, [%s -> %s]", > > + fio_filename(source_fd), > > + fio_filename(dest_fd)); > > Other coio/fio methods don't log errors so I don't think this one > should, either. But fio_ methods which we used before the patch do print an error, so we should continue printings. > An extract from the sendfile manual page: > > } sendfile() will transfer at most 0x7ffff000 (2,147,479,552) bytes, > } returning the number of bytes actually transferred. (This is true on > } both 32-bit and 64-bit systems.) > > So I don't think using sendfile is equivalent to read+write... Actaully man page is a bit wrong, at most it may handle up to 0x7fffffff bytes. And here is a question do we really ever going to transfer such big files? Moreover using read/write with 4K buffer for big files is pure and utter crap, the only thing which saves situation a bit is a page cache, but still such small buffer requires a number of context switches :) 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 :)