questionbot Posted September 6, 2021 Share Posted September 6, 2021 (edited) 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, 2021 by questionbot Quote Link to comment
trurl Posted September 6, 2021 Share Posted September 6, 2021 Sep 5 21:27:14 serverox emhttpd: unclean shutdown detected Quote Link to comment
itimpi Posted September 6, 2021 Share Posted September 6, 2021 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. 1 Quote Link to comment
questionbot Posted September 6, 2021 Author Share Posted September 6, 2021 (edited) 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, 2021 by questionbot Quote Link to comment
itimpi Posted September 6, 2021 Share Posted September 6, 2021 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. 1 Quote Link to comment
questionbot Posted September 7, 2021 Author Share Posted September 7, 2021 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... Quote Link to comment
questionbot Posted September 7, 2021 Author Share Posted September 7, 2021 I also installed a plugin I read about called "fix common problems".... the "full scan" is still in progress... Quote Link to comment
ChatNoir Posted September 7, 2021 Share Posted September 7, 2021 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 ? 1 Quote Link to comment
questionbot Posted September 7, 2021 Author Share Posted September 7, 2021 Changed it from "custom" to monthly, like you suggested. Quote Link to comment
itimpi Posted September 7, 2021 Share Posted September 7, 2021 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. 1 Quote Link to comment
questionbot Posted September 8, 2021 Author Share Posted September 8, 2021 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? Quote Link to comment
trurl Posted September 8, 2021 Share Posted September 8, 2021 It means scheduled parity checks will be correcting checks. Not recommended for reasons already given. 1 Quote Link to comment
trurl Posted September 8, 2021 Share Posted September 8, 2021 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? 1 Quote Link to comment
questionbot Posted September 8, 2021 Author Share Posted September 8, 2021 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. Quote Link to comment
itimpi Posted September 8, 2021 Share Posted September 8, 2021 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. 1 Quote Link to comment
questionbot Posted September 8, 2021 Author Share Posted September 8, 2021 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. Quote Link to comment
itimpi Posted September 8, 2021 Share Posted September 8, 2021 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. 1 Quote Link to comment
questionbot Posted September 9, 2021 Author Share Posted September 9, 2021 (edited) 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, 2021 by questionbot 1 Quote Link to comment
Recommended Posts
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.