Can only share what not to do. (and then mainly for other people who come looking for suggestions :S)
In trying to acheive the same thing I thought: plug the drives into the USB ports on the NAS, ssh in and do a straight:
mv /mnt/USB/[drive]/ /mnt/HD/Drive/mynewshare/
being USB 3 it should be about the quickest option, right? I had 4 or 5 tb’s of data to copy. I would have thought 10, maybe 15 hours. Boy! How wrong was I?! I’m at around 36 hours and counting.
Noticed the processor was very busy in the console. So then running top led me to research wdphotomerger and I found this:
And then stopped the daemon:
/etc/init.d/wdphotomergerd stop
Which did speed things up a bit but not that much. CPU is still sitting on 100% and spiking down to 90% every couple of seconds. Its like its in opposite world. At least its just what you’d expect hogging the CPU (the mv command and ntfs and raid drivers).
And annoyingly, mv actually failed to remove the source on random files for some reason. It seems have copied ok but left the odd file behind. Can’t see any reason for it. I’ve tried to give it as free a run as possible. nothing else has a grab on those files. Possibly its crappy ntfs drivers.
I don’t know what speed those onboard usb 3 ports are supposed to achieve, but it doesn’t seem to perform anywhere near as well as the same drives plugged directly into my intel nuc (running xubuntu).
If I had my time again, I’d probably try plugging them into a reliable and known USB 3 (in my case, the nuc or my work laptop) and copying over the network. Maybe I’d try scp or rsync or maybe even ftp to do the heavy lifting. I don’t know that I could trust the onboard usb. Don’t think its up to the task.
