[linux-cifs-client] Degression? Simultaneous writing to second mounted share terribly slow since cifs.ko 1.45 (maybe since 1.41).

[Jan Kandziora]

Hello,

I have a problem when copying files from or to multiple shares on a MS-Windows 
2000 Server mounted with cifs.


Background:
===========
I'll backup files from a MS-Windows 2003 server through a Linux server. Until 
recently, I used SuSE9.3 on the Linux box and mounted two shares from the 
MS-Windows server with "smbfs". The backup needed about 3 hours to copy all 
the data (about 15GB). A week before, I have updated the Linux box to 
openSuSE10.2 (linux-2.6.18.8,cifs.ko: V1.45), changed the "smbmount" command 
to mount -tcifs (mount.cifs: V3.0.23d) and thought it was ok, as the command 
worked and I could copy files both directions.

But later, I found out the backup was terribly slow now, it took about 20 
hours instead of 3. Annoying.


Investigation on the problem (caution, long story):
===================================================
After some searching on this topic, I found out there could be a problem with 
autonegiogation of the LAN adaptor. I really was, so I set the link speed to 
100MBit/s and disabled autonegiogation. I tested the speed of the connection 
with

$ dd if=/dev/zero of=/mnt/share1/foo bs=1M count=10

and came to ~8MB/s after that. Good, I expected no problems any more...


But that isn't the whole story. The backup operator told me the backup took 
still too long. So I investigated again. He was right. Copying a single file 
at a time was fast, so I copied two files at once

$ dd if=/dev/zero of=/mnt/share1/foo bs=1M count=10 & dd if=/dev/zero 
of=/mnt/share1/bar bs=1M count=10

I expected ~4MB/s, but it took about *25* seconds to copy those 20MB. Hmmm.


Noticing the shares were mounted "rw,mand", I checked the mount.cifs manpage 
and found out about the "nobrl" option, which I used to disable byte range 
locks. Now the "mand" was away and copying a single file was working as 
before. I tested again, with the command above and now everything was fine, 
5MB/s even when coping two files at a time.


Well, this is not the end of the story. I made a backup, just wo make sure 
everything was working fine, and it worked fine for the first mounted share. 
But when it came to the second mounted share (from the same MS Windows 
server), the speed was going down to 500KB/s again. WTF?

After terminating the test backup, I ran

$ dd if=/dev/zero of=/mnt/share1/foo bs=1M count=10 & dd if=/dev/zero 
of=/mnt/share1/bar bs=1M count=10 & dd if=/dev/zero of=/mnt/share2/foobar 
bs=1M count=10

This was fast. But

$ dd if=/dev/zero of=/mnt/share1/foo bs=1M count=10 & dd if=/dev/zero 
of=/mnt/share1/bar bs=1M count=10 & dd if=/dev/zero of=/mnt/share2/foobar 
bs=1M count=10 & dd if=/dev/zero of=/mnt/share2/barfoo bs=1M count=10

was slow like molasses with both /mnt/share2 dd's.


I tried this with various permutations of mounting /mnt/share1 
and /mnt/share2, dd'ed in both directions etc. It was always the same: 
Copying two files at a time to or from the *second mounted* cifs share was 
slow, while copying to or from the share which was mounted first was fast.


Test with other versions of cifs.ko, other mount.cifs and another Linux Box.
============================================================================
First I have tried to upgrade to a recent cifs.ko and mount.cifs. I upgraded 
the server to 2.6.24-rc5 (cifs.ko: V1.52) and mount.cifs to 3.0.28. This 
didn't help at all.

Then I have tried the same from a Linux desktop PC (openSuSE10.1, 
linux-2.6.16, cifs.ko: V1.40, mount.cifs: 3.0.22) and there, to my surprise, 
all dd's from above ran fast. I could even copy fast to the Linux server 
(running samba3) at the same time.


Another observation: While there is one "cifsd" kernel thread *per mounted 
share* on the (buggy) Linux server, there is only one "cifsd" kernel thread 
*per remote server* on the Linux desktop PC. Maybe a race condition?


Any ideas what was changed since cifs.ko 1.40?


Kind regards

	Jan
-- 
Really, I'm not out to destroy Microsoft. That will just be a
completely unintentional side effect. -- Linus Torvalds