Please support SMB3 server side copy. Using explorer we can copy a 2GB file easily in less than a second. Using DOpus it runs at ~17MB/s (takes around 3 minutes) on fast gigabit hardware (usually ~100MB/s).
see e.g. wiki.samba.org/index.php/Server-Side_Copy
Tested using SAMBA 4.1.7 x64, Windows 8.1u1 x64 and Opus 11.3.
@jhn431
"Server Side Copy" has actually nothing to with that copy_buffer_size.
It is there to avoid receiving and sending a file over the network, if the copy can be done completly on the remote system. Copying something from "\server\share-a" to "\server\share-b" e.g.
Thanks, I did find that option myself plus unbuffered threshold and played around with it, but speed is still far below explorer speeds for standard, non-server side copies (so actually this is offtopic). Using 56GBit LAN (no typo) explorer achieves around 500MB/s (limited by the source), while DOpus even with larger/smaller buffers and/or (un)buffered IO does only 240MB/s at best. For reference a single connection iperf achieves around 5500MB/s (44GBit), while using 2 or more connections achieves almost the full 7GB/s (56GBit) using the very same client/server. So the systems a capable far beyond that speed.
Ontopic: actually it does not work for share-a to -b, but only within one share, because only then can the client tell the server that it can clone that file itself with certainty. At leas in my setup it only works intra-share. It's really nice to copy large files at super high speed regardless of connection speed (e.g. slow VPN!). I used to login via SSH to the Linux box to do large copies on the server, now I just use Explorer instead of DOpus, even though I hate to do so
It's supported since Win2008/7 and SAMBA4.
@tbone
Do you really get ~80MB/s when copying a file from and to the same share (e.g. just press Ctrl+C, Ctrl+V) where the client (DOpus) has to download and immediately upload and the HDDs have to read/write at the "same" time? I get at best 60MB/s using a RAID6 of 6 WD Reds which usually does ~500MB/s. I think you quoted share to local copying or local to local.
I think you mean jhn431?
Reaching 80mb/s and more is possible only when copying local -> remote or remote -> local on gbit ethernet. Ethernet bandwidth for remote -> local -> remote would be to low, and that's the exact sitaution for server side copy.
As others have noted this thread somewhat has got sidtracked talking about an unrelated topic on caching.
This is actually to do with supporting server-side copy operations via the SMB2 FSCTL_SRV_COPYCHUNK request. Clients making use of server-side copy support, such as Windows Server 2012 and Windows 8, can experience considerable performance improvements for file copy operations, as file data need not traverse the network.
Windows Explorer and Robocopy supports SMB2 FSCTL_SRV_COPYCHUNK. The question is are there any plans for Directory Opus to also support SMB2 FSCTL_SRV_COPYCHUNK?
In the future we will be adding an option (on by default) to use the shell to copy things where possible (not for archive extraction etc. that the shell cannot do), which should cover this.
Please also link your account to make feature requests or bump ancient threads with nothing more than "bump".
Nearly all Dopus users seem to have all their data on local storage, I thought there'd be more industrial sysadmin type users, this is a basic feature...