On 09/08/2015 04:45 PM, Darrick J. Wong wrote:
On Tue, Sep 08, 2015 at 11:08:03AM -0400, Anna Schumaker wrote:
quoted
On 09/05/2015 04:33 AM, Al Viro wrote:
quoted
On Fri, Sep 04, 2015 at 04:25:27PM -0600, Andreas Dilger wrote:
quoted
This is a bit of a surprising result, since in my testing in the
past, copy_{to/from}_user() is a major consumer of CPU time (50%
of a CPU core at 1GB/s). What backing filesystem did you test on?
While we are at it, was cp(1) using read(2)/write(2) loop or was it using
something else (sendfile(2), for example)?
cp uses a read / write loop, and has some heuristics for guessing an optimum buffer size.
..but afaict cp doesn't fsync at the end, which means it's possible that
the destination file's blocks are still delalloc and nothing's been flushed
to disk yet. What happens if you time (cp /tmp/a /tmp/b ; sync) ?
That's already how I was using cp :). The example program in my man page also doesn't fsync at the end, so the extra sync at the end is needed for both.
Anna
2048M / 1.667s = ~1200MB/s.
--D
quoted
Anna
quoted
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html