Running the latest version of unraid, first monthly full parity check with latest version...web interface not existent...pings fine, can ssh to server fine...tried diagnostics from the command line and pulled syslog directly...when attempting to copy the zip/syslog through winscp, the small file copy kept on hanging, disconnecting and I had to keep reconnecting/resuming the file to get it finally...his is what I got...Is this a kernel/memory issue? Raid card did not scram any of the drives (from the raid network interface)...Nothing has been touched on the server for several months now.

 

syslog-2018-11-02 CUT.txt

 

 

 

EDIT: suspected that the docker container that I have autoupdating was causing issues, I shutdown the docker (/etc/rc,d/rc.docker stop), it did stop successfully...I then issued powerdown -r and it is taking forever "unmounting local filesystem"... it had a few errors too...attached a screenshot. It took forever to finally release the local filesystem before reboot...luckily, it did shut down gracefully...I seem to have bad days when a hard boot is necessary! We'll see if the problem rearises. restarting parity check.

 

 

 

 

Edited November 2, 20187 yr by bsim

Restarted Parity check...one of my ST5000DM000's came back with a ton of parity errors! Of course just outside of warranty, but also found drive was a referb and not new...ordered from Amazon as new! Time for the old swapola!

 

For the future...is there a clue in the syslog that would have clued me into an issue with one of the drives failing a parity check before I run it?

Edited November 2, 20187 yr by bsim

Server is having constant call traces during the parity check, this can usually be alleviated by lowering the tunables.

Has tunables been worked out as far as knowing typical usage values for an 8GB dual processor server? I saw that 6.1.4 introduced md_sync_thresh (default set to md_sync_window/2)...I've read all of the site on tunables, but other than the default being made for 512M memory, and finding a lot of cryptic guesses and wild testing goose chases...I can't find a good solid list of tunables to support much more memory. I've seen the tunables tester script, but it hasn't been updated in several years.

 

I attached a current list of my tunables for a 24 drive array with 8GB...are they too aggressive? With these settings, a full parity check only uses 26% and 38% of memory.

 

I pulled my defaults from...now seeing it was for a 32GB system...perhaps I was a bit too agressive.

 

 

 

 

 

Edited November 2, 20187 yr by bsim

16 minutes ago, bsim said:

I attached a current list of my tunables for a 24 drive array with 8GB...are they too aggressive?

Those are fine, unless you get call traces during a check.

If I get call traces, is there one tunable that I need to back off the most?

According to a recent user md_sync_thresh was the only one that made a difference for him.