Did some informal testing of Jeff Layton's cifs async_write patch set
tonight (recent kernel). Copying 700MB sequentially was 20% faster
from cifs kernel client to Samba 3.6 with his patches - even mounted
over localhost (where network latency is a much smaller issue) and
with a slow laptop drive!
I was simply doing
time dd if=/dev/zero of=/mnt/null bs=1M count=700
repeated 4 times each way (with old module, and with same code with
Jeff's cifs async write code builtin), deleting the target file in
between each run.
I am looking forward to trying this over GigE tomorrow to servers with
faster disks.
--
Thanks,
Steve
On Fri, May 27, 2011 at 12:14:19AM -0500, Steve French wrote:
> Did some informal testing of Jeff Layton's cifs async_write patch set
> tonight (recent kernel). Copying 700MB sequentially was 20% faster
> from cifs kernel client to Samba 3.6 with his patches - even mounted
> over localhost (where network latency is a much smaller issue) and
> with a slow laptop drive!
>
> I was simply doing
>
> time dd if=/dev/zero of=/mnt/null bs=1M count=700
>
> repeated 4 times each way (with old module, and with same code with
> Jeff's cifs async write code builtin), deleting the target file in
> between each run.
>
> I am looking forward to trying this over GigE tomorrow to servers with
> faster disks.
Very nice ! Now where's my encrypted transport Steve ? :-) :-)
Jeremy.
On Fri, May 27, 2011 at 11:47 AM, Jeremy Allison <[email protected]> wrote:
> On Fri, May 27, 2011 at 12:14:19AM -0500, Steve French wrote:
>> Did some informal testing of Jeff Layton's cifs async_write patch set
>> tonight (recent kernel). Copying 700MB sequentially was 20% faster
>> from cifs kernel client to Samba 3.6 with his patches - even mounted
>> over localhost (where network latency is a much smaller issue) and
>> with a slow laptop drive!
>>
>> I was simply doing
>>
>> time dd if=/dev/zero of=/mnt/null bs=1M count=700
>>
>> repeated 4 times each way (with old module, and with same code with
>> Jeff's cifs async write code builtin), deleting the target file in
>> between each run.
>>
>> I am looking forward to trying this over GigE tomorrow to servers with
>> faster disks.
Note that Samba defaults to negotiating a 128K write size but sending
"min receivefile size" in smb.conf to a larger value will allow larger
writes. I see slightly better performance on the simple dd test over
localhost network interface with larger wsize of 512K than I do with
the default (128K). I haven't measured the ideal wsize yet but
presumably it will vary depending on network and disk speed and server
load.
> Very nice ! Now where's my encrypted transport Steve ? :-) :-)
First cleanup patch is in (which gracefully handles failing mounts
when server requires encryption and client can't do it). The 2nd
part - the NTLMSSP negotiation inside setfsunixinfo wasn't too bad and
I plan to send out for review within a few days. I haven't written
the piece which uses these credentials to do the encryption yet.
--
Thanks,
Steve
On Fri, May 27, 2011 at 11:47 AM, Jeremy Allison <[email protected]> wrote:
> On Fri, May 27, 2011 at 12:14:19AM -0500, Steve French wrote:
>> Did some informal testing of Jeff Layton's cifs async_write patch set
>> tonight (recent kernel). Copying 700MB sequentially was 20% faster
>> from cifs kernel client to Samba 3.6 with his patches - even mounted
>> over localhost (where network latency is a much smaller issue) and
>> with a slow laptop drive!
>>
>> I was simply doing
>>
>> time dd if=/dev/zero of=/mnt/null bs=1M count=700
>>
>> repeated 4 times each way (with old module, and with same code with
>> Jeff's cifs async write code builtin), deleting the target file in
>> between each run.
>>
>> I am looking forward to trying this over GigE tomorrow to servers with
>> faster disks.
>
> Very nice ! Now where's my encrypted transport Steve ? :-) :-)
>
> Jeremy.
Did some additional informal testing with this (current mainline vs.
cifs from 2.6.39) and the results are even better.
Mounted over GiGE to midrange desktop system from my laptop. Copying
2.5GB to the server was 88% faster with current mainline. Repeated
the test 3 times each way. Current mainline cifs averaged 98.9 MB/s
for sequential file copy vs. 52.6 MB/s (for 2.6.39 and older).
stevef@stevef-laptop:~$ time dd if=/dev/zero of=/mnt/null bs=1M count=2500
2500+0 records in
2500+0 records out
2621440000 bytes (2.6 GB) copied, 26.3095 s, 99.6 MB/s
real 0m27.201s
user 0m0.000s
sys 0m3.340s
--
Thanks,
Steve