From: Dave Chinner <david@fromorbit.com>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Steve French <smfrench@gmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Copy tools on Linux
Date: Mon, 2 Jul 2018 10:17:05 +1000 [thread overview]
Message-ID: <20180702001705.GS19934@dastard> (raw)
In-Reply-To: <20180701174443.6lrpuurx5stsyvja@merlin>
On Sun, Jul 01, 2018 at 12:44:43PM -0500, Goldwyn Rodrigues wrote:
> On 07-01 10:10, Dave Chinner wrote:
> > On Fri, Jun 29, 2018 at 09:37:27PM -0500, Steve French wrote:
> > > I have been looking at i/o patterns from various copy tools on Linux,
> > > and it is pretty discouraging - I am hoping that I am forgetting an
> > > important one that someone can point me to ...
> > >
> > > Some general problems:
> > > 1) if source and target on the same file system it would be nice to
> > > call the copy_file_range syscall (AFAIK only test tools call that),
> > > although in some cases at least cp can do it for --reflink
> >
> > copy_file_range() should be made to do the right thing in as many
> > scnearios as we can document, and then switch userspace over to use
> > it at all times. Aggregate all the knowledge in one place, where we
> > know what the filesystem implementations are and can get hints to do
> > the right thing.
>
> We have discussed this earlier in
> https://www.spinics.net/lists/linux-fsdevel/msg125401.html
> and Christoph suggested that there is no point adding new flags
> for holes. Do you have a different opinion?
I don't care. All I was suggesting is that we add flags to...
> The same is with coreutils maintainer where he suggested adding
> flags to perform everything with respect to holes in the kernel.
.... get adoption from the userspace tool maintainers who won't use
anything that doesn't exactly replace what they do now.
And that's the real problem - getting userspace to use all the
go-fast bits we provide. How long have we had the splice interfaces
to do efficient data copies without passing data through userspace?
You'd think using these APIs would be a no-brainer, but nothing uses
them at all. I suspect we're going to see the same thing with
copy_file_range() and similar recent advances in AIO+DIO APIs...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2018-07-02 0:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-30 2:37 Copy tools on Linux Steve French
2018-06-30 13:13 ` Goldwyn Rodrigues
2018-06-30 14:12 ` Steve French
2018-06-30 14:47 ` Goldwyn Rodrigues
2018-06-30 16:34 ` Andreas Dilger
2018-07-01 0:10 ` Dave Chinner
2018-07-01 2:59 ` Steve French
2018-07-01 17:44 ` Goldwyn Rodrigues
2018-07-02 0:17 ` Dave Chinner [this message]
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=20180702001705.GS19934@dastard \
--to=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rgoldwyn@suse.de \
--cc=smfrench@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).