To confirm, we are talking about writing 2 gigaBYTES per second? That makes this test and the device very unusual.
I am assuming the DS3615xs achieves this by writing to all 12 drives at once in parallel, since no single normal HDD or SSD exists that can come close to maintaining that speed. That could also make the DS3615xs very sensitive to how the data is sent to it.
Where is the data coming from that can read that fast? Another DS3615xs, or a RAM disk or similar?
We'd like to set up a similar test, but devices that can even approach those speeds are rare and costly, and we could end up buying them just to find the problem was outside of Opus.
What happens if you use xcopy or robocopy from a command prompt? Those are examples that won't use the shell file copy API (although they won't be identical to Opus, either).
To back up what I'm saying about some Synology devices being sensitive to minor details of how data is written to them, as well as being improved by Synology's software updates, here are a couple of threads:
- Slow network file copy - #12 by Leo
- Affected both Opus and TeraCopy, but not Explorer.
- "Problem can be fixed by creating an iSCSI target on my NAS."
- "Synology recently released an update DSM 3.2-1955 to their NAS software that fixed the slow copy issue."
- Copy to a Share folder (temporarily) hangs at the end - #14 by SusiBiker
Synology have a File Server Performance area on their forum. It may be worth posting there to see what they think.
Another thing to check: Is there high CPU load during the copy? From dopus.exe or another process? That could indicate something is causing a bottleneck.
Have you tried extremely large buffer sizes? Things generally default to 64KB but that will be extremely small if you're transferring at 2GB/s. Setting the copy buffer size to 1MB, 10MB or 100MB to test with those is worth a try. (If you're familiar with Process Monitor, you can also use that to see which buffer sizes Explorer is using when it copies to the device. It may have logic to switch to larger sizes for extremely fast devices.)
I would also try those buffer sizes in combination with the non-buffered I/O set to both 1MB and 0. (So 6 tests in all.)
(Non-buffered I/O being turned on often helps, and will also result in the read and write sides being done in parallel by Opus rather than by the OS, but this can cause pathological issues with some devices as well, as some are only tested for buffered I/O. Note that the copy buffer size is independent of the non-buffered I/O setting; they are about different buffers: One in Opus itself, and the other in the OS/filesystem stack. The non-buffered I/O setting is more an on/off than a buffer size: It specifies the minimum file size before non-buffered I/O is used to copy that file, since it will often slow things down with very small files, even on devices which work well with non-buffered I/O.)