Hello Everyone !

 

I've a weird behaviour with my parity check. I had a first parity check that ended yesterday. and right after, a new one started. but the new one is extremely slow !

my history:

 

the one that is running right now:

 

Can someone help me ? 2-3days is already long for a check... I can't wait 45 days !

What should I check ?

thx for your help !

 

Edited February 10, 20233 yr by N47H4N

There's something else reading from disks 1, 6 and 10.

13 hours ago, JorgeB said:

There's something else reading from disks 1, 6 and 10.

thank you @JorgeB to had a look on my diag file. How can I find what's reading the disks 1,6 and 10 ? docker & VM are off but still slow.

 

Also, do we have an explanation why a new parity check started right after the last one ended?

Disable docker and VM services and post new diags.

 

after 6 days... it just finish right now ! but... 

 

 

it started again for the 3rd time...

 

I really need help please. Something is wrong here...

On 1/5/2023 at 9:28 AM, JorgeB said:

Disable docker and VM services and post new diags.

during a check

Check is going at about 110MB/s, seems pretty reasonable.

On 1/4/2023 at 5:46 PM, N47H4N said:

I've a weird behaviour with my parity check. I had a first parity check that ended yesterday. and right after, a new one started

You might want to post the output of

cat /etc/cron.d/root

so we can check what schedule you have set for parity checks.  It is possible to get combinations of settings that can cause you symptoms.

8 hours ago, JorgeB said:

Check is going at about 110MB/s, seems pretty reasonable.

The problem is not really the speed, it's more.. why when the check finish, a new one starts right after

 

8 hours ago, itimpi said:

You might want to post the output of

cat /etc/cron.d/root

so we can check what schedule you have set for parity checks.  It is possible to get combinations of settings that can cause you symptoms.

 

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
40 3 * * * /usr/local/sbin/mover &> /dev/null

# Generated parity check schedule:
0 0 1 * * /usr/local/sbin/mdcmd check  &> /dev/null

# CRON for CA background scanning of applications
59 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

# Generated schedules for parity.check.tuning
15 0 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
30 3 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
*/6 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

4 minutes ago, N47H4N said:

when the check finish, a new one starts right after

Did you reboot before the new one started?

Jan  9 19:48:55 NAS01  emhttpd: unclean shutdown detected

 

21 minutes ago, N47H4N said:

The problem is not really the speed, it's more.. why when the check finish, a new one starts right after

Sorry, misread the post before, and with the thread title...

1 hour ago, trurl said:

Did you reboot before the new one started?

Jan  9 19:48:55 NAS01  emhttpd: unclean shutdown detected

 

yes I've reboot but it was a clean reboot. I didn't stop the array but I use the restart button from Unraid

I'm specifically asking if the repeat parity check started after you rebooted 

5 minutes ago, trurl said:

I'm specifically asking if the repeat parity check started after you rebooted 

yes

Then unclean shutdown is the most likely cause. 

but as I mention, it was a clean one. Do I need to stop the array before ?

Doesn't matter what you did. What matters is if Unraid knows the array was stopped before it was rebooted. 

 

Unraid records that array status on the flash drive. If shutdown times out before the array is stopped, or if that status can't be written to flash for some other reason, then it is unclean as far as Unraid knows. 

 

That reboot yesterday was unclean as indicated in your syslog. 

There is a thread pinned near the top of this General Support subforum all about unclean shutdowns.

 

ok, understood, thx for your help !

still the same problem, even if I stop docker and VMs

nas01-diagnostics-20230207-0633.zip

There's something writing to disk9.

Hello @JorgeB, how can I investigage further what is writing to this disk ?

If all dockers/Vms are stopped it must be a local/LAN transfer, if you can't find it disable SMB to see if it stops.

this parity check make me crazy..  it takes weeks ! even if I stop Docker & VMs it takes days.... how other users manage that ? My firewall, so during few days I've no internet only because of this parity check...

And every time I restart my unraid, it start again a parity check... even with a clean restart. That's the case today again. What I did:

- Wait 6 days for the parity check without docker & VM & Internet

- Stop the array

- restart from Gui

- Then parity check start again

 

 

nas01-diagnostics-20230208-0634.zip

Edited February 8, 20233 yr by N47H4N

The latest diagnostics show that an unclean shutdown was still detected

Feb  8 06:31:25 NAS01  emhttpd: unclean shutdown detected

If as you say you stopped the array before the reboot then this suggests that Unraid might have had problems with writing back to the flash drive that the array had been successfully stopped.   Have you had any issues with the flash drive?