Hey guys, I'm copying a share from one volume to a new volume through SSH using MC (Midnight Commander) and I'm getting an avg of 6.33MB/s. Going to take 35mins or so to copy 14GB.
I know this unit is a bit slow for ram/cpu but this seems like a 10th of what it should be able to do.
Thoughts before I move onto the other 5 TERABYTES?
I keep pasting this info in the thread and the post keeps disappearing.
Anyhow there's no errors for that (any) drive in the log file. If someone can help me understand why I can't paste the contents in the message, then perhaps I can do that.
All three disks look fine to me, and since this is JBOD there shouldn't be any issue with sync.
MC is running on the NAS?
Perhaps try a test using a backup job (configured in the web ui) to transfer the same share (to a different target on the new disk) and see if that shows better throughput. Might be good to reboot the NAS before you do this.
Yeah so last night I already added a backup job while the 310GB share (eta of about 7hrs) was chugging along. This morning neither had completed and the MC SSH'd (yes SSH'd into the nas, using MC on the NAS itself, no network copying in play here) copy of one of the shares was at half it's avg throughput (presumed the other half of the bandwidth was taken up by the backup process).
So backup process is doing a share right now and MC is actively copying files with a reported avg of 5.45MB/s (current large file it's on is 4.8mb/s).
So painful.
Whenever this finishes I'll run the performance test I see others run. I'll also try copying a file in the inverse direction to see if it might be related to the drive hardware/firmware.
For $#!ts and Giggles I tried copying from one share to another on my PC (Win 10), again from share to share. I'm getting 30-40MB/s! It'll copy 20GB in 9-10mins. And this is while one of my backup jobs (2.3TB of data in that share, has only managed about 10% of it's job in 5 hours) is still going.
What is going on that copying within linux, on the device itself, is 1/3rd the speed?
Obviously, I'm going to copy the rest of the volume... over the network (whhhhaaaat?).
The 'minidlnad' processed eventually dropped off 'top' and went down to sub 6%. Though curiously the amount of memory in use stayed the same.
When my SMB copy stopped, I stopped readynasd (as it was always trying to take up 100% of the cpu) and then started it and it started to behave "normally" (only spiking when using the management console). However, I tried another copy within midnight commander, large file, and it still didn't go over 10mb/s while the SMB copy with readynasd under control and no other backup process happening would top out in the mid 50's (generally hanging around in the mid 40's). smbd around migh 50 to mid 60% cpu, which kicks up kswapd0 to low teens. 3 kworker processes, usually 2 of them equal 10%.
When I sort 'top' by mem%, 'minidlnad' it's the highest (at 5.6%) but no other process seems to be using a lot of memory despite 480000 used and only ~30000 free. The swap looks much better now though, only 10,416 used. 3-5 running tasks, 187(!) sleeping (0 stopped or zombie).
So yeah this is still quite odd why smb copies so much faster. Haven't rebooted yet, ALMOST done migrating all my data over. Just a few more hours now.
So, after powering down. Moving my new drive that I was copying all this data to into another slot, turning it back on. Then shutting down again and reinstalling an exported 2-disk volume, turning it back on to verify it worked. Then exporting it again, removing it. Putting two other disks in, creating a RAID 0 volume of those and manually editing smb.conf (which was not loading due to "smb encryption = (null)"). I created some backup jobs to backup data from the Bay 1 drive to this new array and I'mgetting an avg of 44mb/s through the management console and using the backup jobs.
So it appears, somewhere in that process, part of my problem(s) corrected themselves.
Once the backups are done, I'll run the various commands and tests mentioned here and post the results for future reference.
Going to probably need to start another thread on the SMB config issue because as soon as I reboot, it will overwrite my change, so somewhere else in the system is some thing else that needs to change, or I need help to write a script to update and re-try 'systemctl start smb' after a minute or two after booting. Anyhow, separate issue (but part of the odyssey of this single drive upgrade project).
