[SOLVED] - System keeps running Piarity-Checks, even on "clean" reboot?


Recommended Posts

I have been having a issue where I started to notice slow downs... it seems that my system is constantly doing parity-check... and I do not know why or how to fix it.

 

I thought I would do a small bit of maintenance and see how it all went...

 

  1. I waited for the current parity-check to end
  2. I updated all my dockers (nothing errored)
  3. I turned off all the dockers and disabled the service
  4. I ran the mover
  5. i turned on the docker service
  6. I clicked the "reboot" button, which as I understand it dose a safe reboot.

 

So the thing rebooted and then instantly started a parity-check. At time of this post it is at 0.6% It usually takes about 22 hours or so. I run 3 16TB drives, with 1 as a parity disk, with a 250GB SSD cache (I plan to upgrade this to a 1GB ssd when I add my next 16TB drive)

 

Anyway... any ideas what is going on? I have the "scheduler" installed and as I understand it I have it set to do a full scan once every 3 months, so 4 times a year.

 

Thanks!

 

SOLUTION : Seams I had the schedule set up wrong. Adjusting the schedule settings fixed the issue. So there was no unraid error at all, it was just user error.

 

serverox-diagnostics-20210906-1429.zip

Edited by questionbot
Link to comment

Item 6 is not quite true - the reboot is not necessarily ‘safe’.  I

 

t is only ‘safe’ if the timeouts for stopping docker containers, VMs and unmounting disks are not triggered AND the shutdown status can be recorded on the flash drive.   It would be ‘safe’ if prior to clicking on Reboot you had first used the ’Stop’ option to stop the array and that had succeeded.

 

I would suggest that you try:

  • clicking the ‘Stop’ option to ensure that the the docker and VM services can be stopped and the disks unmounted, and time how long that takes.  
  • If the system sticks on trying to unmount the disks then you will need to investigate what is preventing that from happening and rectify that.  
  • Assuming that the Stop completes you can now try the Reboot to confirm the system was able to update the flash drive and the reboot no longer causes an automatic parity check.  
  • If that is OK you now have the information you need to adjust the timeouts to get clean reboots in the future.
  • Like 1
Link to comment

Ok... thanks.. I'll defiantly do all that....  but the "clean reboot" was not the actual problem.. I just thought it was a symptom of it.

 

Like I said in the OP, the parity-check just kept triggering all the time. It starts again and again without rebooting...

 

Last reboot before this one was 30+ days ago, the time before 50+... but it seems that the parity-check is just constantly turning on all the time.

Edited by questionbot
Link to comment
1 hour ago, questionbot said:

Ok... thanks.. I'll defiantly do all that....  but the "clean reboot" was not the actual problem.. I just thought it was a symptom of it.

 

Like I said in the OP, the parity-check just kept triggering all the time. It starts again and again without rebooting...

 

Ah - misunderstood your problem.   I was assuming either a reboot or a shutdown/restart.

 

As far as I know the only way to automatically start a parity check while running is via what is set under Settings->Scheduler so you might check those.

 

The contents of /etc/cron.d/root might also be worth posting as a check.

 

 

  • Like 1
Link to comment

Had to wait for current check to end before accessing the scheduler.. it seems I can only click it form the main page, but the link is not there while it is running.

 

I have it set to MONTHLY at 3:00am... with 3 months between checks. It still says "daily" and "weekly"... if I click on daily nothing it ticked, if I click on weekly there are no tick boxes... and if I click on monthly you can see the ticks...

Clipboard-1.jpg

Clipboard-2.jpg

Clipboard-3.jpg

Clipboard-1.jpg

Link to comment

It is normally recommended that the option to Write Corrections as part of a scheduled test set to No.   the rationale is that if you have a disk that is playing up and you have not realised it you do not want to allow it to corrupt parity thus potentially prejudicing good recovery of any other disk that might have problems.   I always suggest to not write corrections to parity until you have rectified (and hopefully fixed) whatever caused the problem in the first place.

  • Like 1
Link to comment

Since you apparently had scheduled checks running too frequently, changing the schedule might be the fix for all the parity checks you were getting, but...

 

On 9/6/2021 at 1:03 AM, trurl said:
Sep  5 21:27:14 serverox emhttpd: unclean shutdown detected

 

 

Do you know why you had an unclean shutdown?

  • Like 1
Link to comment

I'm pretty sure it was a shutdown error from not having the correctly set timeouts.. I have had the faq thing linked in this thread and stuff.

 

I have the thing set to monthly now like suggested.. and it has not started again since I rebooted the server.. I was going to wait a week before making solved.. but it seems it was a error in my schedule setting the entire time... maybe.

 

2 hours ago, trurl said:

It means scheduled parity checks will be correcting checks. Not recommended for reasons already given.

 

yeah, I mean.. what dose that mean though. Like I have it turned off.. but that means it will still act as data recovery if needed... I do not know what "correcting checks" means.

Link to comment
1 hour ago, questionbot said:

yeah, I mean.. what dose that mean though. Like I have it turned off.. but that means it will still act as data recovery if needed... I do not know what "correcting checks" means.


A ‘correcting’ check means that if a mismatch is found between the array drives and the parity disk then Unraid should automatically assume the data disks are correct and it is the parity disk that is wrong and alter the parity disk so it again matches the data disks.  
 

 In the normal scheduled (monthly?) check one should expect 0 errors being reported and as long as then in that case it makes no difference whether the check was a correcting one or not.   It is only if you get a non-zero value that you want to look into why.   

  • Like 1
Link to comment
1 hour ago, questionbot said:

oh I see... I thought eveytime you change the content of the drive it needs to be updated. So if I copied a bunch of files to the server, it needs to update everything for that data to be insured.

Yes - but is done in real time as the data is copied.   It is the overhead of simultaneously updating the parity as described here that causes write speeds to the array to be relatively slow.

  • Like 1
Link to comment
  • questionbot changed the title to [SOLVED] - System keeps running Piarity-Checks, even on "clean" reboot?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.