unRAID unresponsive/disconnects (no array access through SMB, no web access, and sometimes no console) every time I copy 10s GBs from cache to the array using a Windows PC.

On the 2nd-3rd file (after about 10GB) copy is halted, and the server stops responding.

Different PC - same results.

Normal use all is ok: without copying I don't have any problems.

Also single small/medium size file copy ends normally.

Diagnostics attached.

 

Thanks for any help.

juno-diagnostics-20170223-1353.zip

Why are you copying from cache to array over the network instead of just letting mover do the work?

I'm curious as to why you're using Windows to copy tens of gigabytes from cache to array. Normally Windows would write to or read from a user share and unRAID's own processes deal with managing the cache. So you may well be doing something that's completely unnecessary. Can you explain what it is that you are trying to achieve?

 

Your syslog shows a number of call traces associated with page allocation stalls:

 

Quote

Feb 23 12:56:13 Juno kernel: init: page allocation stalls for 71144ms, order:0, mode:0x26040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK)
Feb 23 12:56:13 Juno kernel: CPU: 6 PID: 1 Comm: init Not tainted 4.9.10-unRAID #1
Feb 23 12:56:13 Juno kernel: Hardware name: Supermicro Super Server/X10SDV-4C-7TP4F, BIOS 1.0 04/07/2016
Feb 23 12:56:13 Juno kernel: ffffc90003163a38 ffffffff813a353e 0000000000000001 0000000000000000
Feb 23 12:56:13 Juno kernel: ffffc90003163ac8 ffffffff810cb40d 026040c07fffab80 ffffffff8193d200
Feb 23 12:56:13 Juno kernel: ffffc90003163a60 ffffffff00000010 ffffc90003163ad8 ffffc90003163a78

 

which may or may not be a manifestation of a bug in Linux kernel 4.9, discussed here. You might want to try a different kernel - in practice that means either rolling back or waiting for a new release. Or maybe you can avoid the scenario by not using Windows to move between cache and array.

 

EDIT: trurl replied while I was composing this.

Copy from windows instead using the mover

Not using the mover mostly because I am in doubt that it would help me.

Also because I am "a bit"  freak control regarding my server and probably a bit lazy to learn the mover.
currently I manage the cache and the disks balance/shares manually. After a media download to the cache I download subs,
copy to the array and sometimes edit file names etc, leaving the original media to seed from the cache.
So where would the mover copy the files to? I don't want them in the permanent array folders before I edit/arrange them.
A second solution (mover moves to a temporary location in the array) includes a second manual copy within the array.

 

Kernel bug

Copies from cache to the array using a PC worked fine before 6.3.1 & 6.3.2 upgrades, so the Kernel bug might well be the reason for my problem.

Why doesn't the kernel bug interferes with mover to array or array to array file copies within the unRAID server?

I used successfully unBALANCE plugin in 6.3.1.

 

I might try the above "second solution", or if someone suggest some efficient way to use the mover I might use it.

Edited February 23, 20179 yr by Gico

All the control you need can be accomplished with proper user share settings. Take some time to learn about them.

If you don't want to follow the advise given I would at least look at Midnight Commander (MC) that is built into unRAID to do the moves from cache to array.  I use it all the time myself.

Yeah, thought of that option too, thanks, but why this bug won't interfere within the unRAID server?

Edited February 23, 20179 yr by Gico

Using Dolphin docker to copy from the cache to the disk and all is ok.

 

Looked again in the kernel bug thread. According to Duncan this problem might be solved with configuration (setting the dirty_ratio).

Someone tried this solution and it worked for him.