On Fri, 24 Sep 2010 11:27:37 +0100 Mike Tonks <fluffymike@xxxxxxxxxxxxxx> wrote: > Hi All, > > I hope this is a suitable place to post this message. I read with > interest a previous thread with a very similar issue: > http://lists.samba.org/archive/linux-cifs-client/2010-January/005504.html > > I have several ubuntu servers here and a remote windows share across a > slow VPN. I'm trying to create a 'folder watcher' to scan > periodically for new files, and this works pretty well using 'ls -la' > and then processing the output in perl. > > In particular, a dev machine: Linux highway-dev 2.6.28-18-generic > #60-Ubuntu SMP Fri Mar 12 04:40:52 UTC 2010 i686 GNU/Linux > > and a production machine: Linux highway-www 2.6.31-19-server > #56-Ubuntu SMP Thu Jan 28 03:40:48 UTC 2010 x86_64 GNU/Linux > > Both dev and production are in the same rack in one location, while > the windows server is at another site. I've tested against other win > servers at other sites with similar results. > > The remote folder has 9000+ files in it. The large number of files is > definately part of the issue, with smaller folders the timing is more > acceptable. > > For a simple 'ls': > > dev: 5 seconds > production: 6 seconds > > For 'ls -la': > > dev: 6 seconds > production: 200 seconds > > Sadly - I need the file size and timestamp for my program to work. > > My question is - can anyone explain what's going on and (hopefully) > help me speed up the response on the production server / identify the > network issue / etc. Or is this something that's changed at a > software level? > > I timed my tests like so: > > $ date; ls /mnt/sharename/ > temp.txt; date > > > $ cat /proc/fs/cifs/DebugData > Display Internal CIFS Data Structures for Debugging > --------------------------------------------------- > ... > 2) Name: x.x.x.x Domain: WORKGROUP Uses: 1 OS: Windows Server 2003 R2 > 3790 Service Pack 2 > NOS: Windows Server 2003 R2 5.2 Capability: 0x1f3fd > SMB session status: 1 TCP status: 1 > Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0 > Shares: > 1) \\x.x.x.x\Jobs Mounts: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x700ff > PathComponentMax: 255 Status: 0x1 type: DISK > > MIDs: There was a fix for a dentry aliasing problem that went in a few months ago (commit f12f98dba6ea1517cd7fbb912208893b9c014c15). That problem could manifest itself in that way. You may want to try a more recent kernel. -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
