Server-side copy with sendfile system call

[Teng-Feng Yang]

Hi David,

Thanks for the quick reply.

I make the function fallback to read/write procedure when src=dest and
pass the smb2.ioctl smbtorture test.
However, I still can reproduce the performance issue mentioned before
by the following steps.

1. Create a 10G test file by dd:
dd if=/dev/zero of=zero_10G.img bs=1G count=10

2. Copy this file into the same directory from remote Windows server.
It is worth mentioning that in the very first time we copy this file,
the throughput shown in Windows will start at 700MB/s and drop down to
120MB/s in a couple of seconds. The throughput number will stay there
throughout the copy process which is normal in my opinion. The
copy_chunk_normal.log was gathered across this copy.

3. Recopy this file into the same directory from remote Windows server.
>From the second time we do the server-side copy, the throughput number
will bouncing up and down between 120MB/s and 0MB/s repeatedly as
mentioned in previous message. The copy_chunk_slow.log was gathered
across this copy.

If you still need any information, please feel free to let me know.
Thanks for your time.

Best Regards,
Dennis

2014-05-22 21:27 GMT+08:00 David Disseldorp <ddiss at suse.de>:
> On Thu, 22 May 2014 18:37:34 +0800, Teng-Feng Yang wrote:
>
>> I already reimplement the vfswrap_copy_chunk_send with sendfile system call.
>> However, I have noticed that the throughput shown in my Windows Server
>> 2012 machine keeps bouncing up and down through the whole copy
>> process.
>> The peak performance is around 140MB/s on a single 4TB harddisk, and
>> then it will drop down to 0MB/s for a couple of seconds before it
>> rises back to 140MB/s again.
>> This repeat pattern results in an overall worse performance than the
>> origin read-then-write version of copy_chunk function.
>>
>> I don't know if I do anything wrong. The following is my version of
>> copy_chunk_send using sendfile().
>> Any comment would be highly appreciated.
>
> Does the modified server pass the smb2.ioctl smbtorture tests? I doubt
> it without the src=dest read/write fallback.
> If it does pass the tests, and you're still seeing this strange
> behaviour, then please take a tcpdump across the copy, and send it to me
> off list.
> The patch looks okay, but is missing the relevant sendfile support
> checks and src=dest fallback as mentioned.
>
> Cheers, David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy_chunk_normal.log
Type: text/x-log
Size: 589824 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140523/1b0a98d5/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy_chunk_slow.log
Type: text/x-log
Size: 593920 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140523/1b0a98d5/attachment-0003.bin>