From: Vladimir Davydov <vdavydov.dev@gmail.com> To: Cyrill Gorcunov <gorcunov@gmail.com> Cc: tml <tarantool-patches@freelists.org> Subject: Re: [PATCH] lib/core/coio_file: Use eio_sendfile_sync instead of a chunk mode Date: Fri, 12 Apr 2019 17:19:16 +0300 [thread overview] Message-ID: <20190412141916.janpwwy27epsfbfv@esperanza> (raw) In-Reply-To: <20190412140558.GB20557@uranus> On Fri, Apr 12, 2019 at 05:05:58PM +0300, Cyrill Gorcunov wrote: > 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. Ah, okay, I see. > > > 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 :) It's not a very hot function, to begin with. I doubt it's used that often or for copying big files. Besides, it is handled in a coio thread (i.e. not in tx) so we can afford it to be a bit slow. > > 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.
next prev parent reply other threads:[~2019-04-12 14:19 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-10 19:36 Cyrill Gorcunov 2019-04-12 13:43 ` Vladimir Davydov 2019-04-12 14:05 ` Cyrill Gorcunov 2019-04-12 14:19 ` Vladimir Davydov [this message] 2019-04-12 14:42 ` Cyrill Gorcunov 2019-04-12 14:53 ` Vladimir Davydov 2019-04-12 14:59 ` 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=20190412141916.janpwwy27epsfbfv@esperanza \ --to=vdavydov.dev@gmail.com \ --cc=gorcunov@gmail.com \ --cc=tarantool-patches@freelists.org \ --subject='Re: [PATCH] lib/core/coio_file: Use eio_sendfile_sync instead of a chunk mode' \ /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