September 6, 20214 yr 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... I waited for the current parity-check to end I updated all my dockers (nothing errored) I turned off all the dockers and disabled the service I ran the mover i turned on the docker service 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 September 9, 20214 yr by questionbot
September 6, 20214 yr Community Expert 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.
September 6, 20214 yr Author 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 September 6, 20214 yr by questionbot
September 6, 20214 yr Community Expert 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.
September 7, 20214 yr Author 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...
September 7, 20214 yr Author I also installed a plugin I read about called "fix common problems".... the "full scan" is still in progress...
September 7, 20214 yr Never tried anything other than a monthly parity check on a fixed date, so I can be mistaking. Your setting look a lot like Parity check runs : every day of every week for January, May and September And since we are in September ... Maybe try to pick a day and a week ?
September 7, 20214 yr Community Expert 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.
September 8, 20214 yr Author ok.. I changed it to being off like you said... dose this mean I need to scan now and then with it turned on? Like what exactly does this option mean?
September 8, 20214 yr Community Expert It means scheduled parity checks will be correcting checks. Not recommended for reasons already given.
September 8, 20214 yr Community Expert 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?
September 8, 20214 yr Author 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.
September 8, 20214 yr Community Expert 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.
September 8, 20214 yr Author 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.
September 8, 20214 yr Community Expert 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.
September 9, 20214 yr Author ok... well I think I am going to mark this solved.. thank you so much for all you help itimpi, ChatNoir and trurl Edited September 9, 20214 yr by questionbot
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.