I recently put a new drive into my array and I want to move some of my TV shows off my older drives which are almost 100% full to my new drive. All my drives are part of the same user share, though in MC I am accessing them as separate disk shares. The speed that Midnight Commander moves these files averages out to be about 2.1 MB/s. The way that it does it is strange though--it has a quick burst where things look like they are going normally for 100 to 200 MB, then it sits there for about a minute like it is stuck. Eventually, it gets unstuck and manages another spurt of a couple hundred megabytes.

 

Has anyone seen this behavior before? Could it be because I have dockers running which are accessing the files? I have it set up so that the split level of the user share keeps all episodes of a show together on one disk. Will Unraid get confused if a show temporarily gets split up between disks during the move process?

If you are moving disk to disk then user shares are not involved at all and so split level is not involved. User share settings just tell unRAID where to write user share files and don't affect reading files in the share.

 

The burst is typical of ram caching. Linux will cache writes in RAM and write it out at whatever speed the drives can handle. Once RAM cache is used up writes will have to wait until some of the RAM is freed by writing to the disks.

 

The slow speed you are getting sounds like a problem, possibly hardware, maybe filesystem corruption. You should post your diagnostics.

Hi trurl,

 

Thanks for your reply. I come from a Windows world and am only a couple of weeks into using Unraid. What sort of diagnostics should I report, and how should I get those reports?

 

If I copy something from outside the array into the array, I get something more like 40 megs a second. It's only when copying from one disk in the array to another that this problem occurs.

 

My RAM usage is hovering around 49% (I have 4 gigs). CPU usage is around 30%.

 

I notice that the original files are still on the first disk, even though I told MC to move the files over. This is not what I expected. However, the procedure is still running (I've spent several hours trying to move about 30 gigs of video). Perhaps it will remove the originals after the move is complete.

I notice that the original files are still on the first disk, even though I told MC to move the files over. This is not what I expected. However, the procedure is still running (I've spent several hours trying to move about 30 gigs of video). Perhaps it will remove the originals after the move is complete.

 

Files will be deleted when the whole operation is completed.

Not just as per completed file operation.

... What sort of diagnostics should I report, and how should I get those reports?...

See v6 help in my sig.

StS82--it was indeed as you said. After 8 hours it finally finished and cleaned up the original files.

 

trurl--I followed your sig and the diagnostics file is attached.

 

In the logs, I noticed these lines:

Jun 13 02:29:30 Tower kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Jun 13 02:29:30 Tower kernel: ata5.00: failed command: WRITE DMA EXT

Jun 13 02:29:30 Tower kernel: ata5.00: cmd 35/00:40:28:1d:98/00:05:04:00:00/e0 tag 16 dma 688128 out

Jun 13 02:29:30 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Jun 13 02:29:30 Tower kernel: ata5.00: status: { DRDY }

Jun 13 02:29:30 Tower kernel: ata5: hard resetting link

Jun 13 02:29:31 Tower kernel: ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 310)

Jun 13 02:29:31 Tower kernel: ata5.00: configured for UDMA/33

Jun 13 02:29:31 Tower kernel: ata5.00: device reported invalid CHS sector 0

Jun 13 02:29:31 Tower kernel: ata5: EH complete

 

They seem to repeat again and again.

tower-diagnostics-20160613-0945.zip

Check connections

Jun 11 23:22:15 Tower kernel: ata5.00: ATA-9: ST4000VN000-1H4168,             Z30146LB, SC43, max UDMA/133

Thanks for the advice--I will check connections when I get home.

 

I'm a bit confused though--if the connection was flawed, wouldn't the disk be unable to transfer data at all?

I recently put a new drive into my array and I want to move some of my TV shows off my older drives which are almost 100% full to my new drive. All my drives are part of the same user share, though in MC I am accessing them as separate disk shares. The speed that Midnight Commander moves these files averages out to be about 2.1 MB/s. The way that it does it is strange though--it has a quick burst where things look like they are going normally for 100 to 200 MB, then it sits there for about a minute like it is stuck. Eventually, it gets unstuck and manages another spurt of a couple hundred megabytes.

 

Has anyone seen this behavior before? Could it be because I have dockers running which are accessing the files? I have it set up so that the split level of the user share keeps all episodes of a show together on one disk. Will Unraid get confused if a show temporarily gets split up between disks during the move process?

 

You can adjust the disk caching with the Tips and Tweaks plugin.  Try changing vm.dirty_background_ratio from 10 to 2, and changing vm.dirty_ratio from 20 to 3 or 4.  It should smooth out the transfers.

The connection felt secure on the drive in question, but just in case, I decided to completely replace the cable. It was like night and day! The transfer rates are fast now (up from 2MB/s to 40MB/s - 80 MB/s). Thanks trurl!

 

RobJ--I do notice that the transfers still aren't 100% smooth, even after cable replacement, so I'll check out that plugin. Maybe there is still room to tweak and improve, but overall I'm pretty happy.