On 09/08/2015 04:45 PM, Darrick J. Wong wrote:
> On Tue, Sep 08, 2015 at 11:08:03AM -0400, Anna Schumaker wrote:
>> On 09/05/2015 04:33 AM, Al Viro wrote:
>>> On Fri, Sep 04, 2015 at 04:25:27PM -0600, Andreas Dilger wrote:
>>>
>>>> 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
>
>>
>> Anna
>>
>>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
