I've just set up the CIFS server on OpenSolaris 2008.05 and I'm experiencing abysmal performance when copying files from the server via SMB to a local drive with DirOpus (9.1.1.0 on Windows XP 32-bit). I can copy a large file from a local drive to the server with about 40 MB/sec but copying from the server to the local drive runs at only 100 kB/sec. It doesn't matter if I use a mounted drive or a UNC path for the share. CPU load on client and server is negligible.
The same copy operation is fast (~ 50 MB/sec) if I do it with "copy" from the Windows command line and it's not much slower when using Windows Explorer. Reading from a share on another Windows machine with DirOpus is fast, too.
It's just the combination of reading + DirOpus + CIFS server which runs so slowly.
Has anyone else experienced this problem (or is using a similar setup but doesn't experience it)?
You may get better results by experimenting with the Copy Buffer size in Opus. Settings -> Preferences / File Operations / Copying Files, at the bottom. I would try much bigger values first but it could be smaller ones that make it word. It's difficult to predict.
If that doesn't help, check the version of Samba on the server if you haven't already. Sometimes you end up with a very old one which can cause problems.
Failing everything else, you could create buttons (or drag & drop context menus or whatever you want) in Opus which copy the files using the DOS copy command, or a tool like TeraCopy or RoboCopy.
I tried some scenarios with different buffer sizes. Copying one large file from the server to the local fs gets much faster with a larger buffer. If I use the maximum size of 9999kB, I can copy at about 30 MB/sec. It's still slower than the 50 MB/sec of Explorer and Copy. A smaller buffer makes copying even slower then before. With 8k I only get 10 kB/sec (yes, that's kB, not MB). The same goes for many smaller files.
Copying the large file from the local fs to the server still gets about 39 MB/sec, irregardless of buffer size. The downside of the large buffer size is that copying many smaller files (tested with JPG and RAW photos of around 1 MB to 10 MB each) from the local fs to the server slows down a lot (from 30 MB/sec at the 64k buffer size to 2 MB/sec at 9999k).
Does anyone know what Windows does differently? Is it using a dynamic buffer size?
I'm using Solaris CIFS server, not Samba, because it integrates nicely with ZFS to provide full Windows ACL support, but I'll set up a Samba server to compare the performance.
A quick update: A buffer size of 128k seems to be the sweet spot. Copying to the server is still as fast as with 64k and copying to the client gets a nice 45 MB/sec. Copying to the client still stops or slows down intermittently but I don't think that is a DirOpus-specific problem.
As an aside, you might find you can speed up the "lots of small files" cases by configuring Opus not to copy attributes and timestamps (assuming you don't want them) when copying files. It won't make much difference with the "a few large files" case, of course.
Explorer copies fewer attributes than Opus and if you're doing a lot of small files, and it takes a significant time to set the attributes each time, then it can add up.
Problem solved! I tried Samba and it had the same problems except that the sweet spot was at a different buffer size (so access from Explorer was very slow; I guess Explorer uses 128k). Something else had to be wrong. I installed a spare Intel Gigabit ethernet card in the server and now the performance is fine at any buffer size. The problems were caused by the on-board RealTek network interface or its driver (even though a netio benchmark showed nothing but stellar results in TCP mode at any block size, much faster than what the old Intel PCI card can deliver). I'll have to look into this further.
I still have a performance problem with the DirOpus standalone image viewer on the CIFS share. Advancing to the next image takes much longer than on a local fs. I'd say its about as slow as opening a new image, so I assume the viewer is not pre-caching the next image on network shares. Can this be changed? I didn't find any option for it in the viewer configuration.