trurl Posted February 7, 2022 Share Posted February 7, 2022 In your screenshot, you can see 32 I/O errors counted on disk1. While these aren't good, they don't mean the disk has "failed", though in this case it might account for the unmountable filesystem. I don't really like the term "failed" anyway since it is often used to mean many different things. One of the reasons I usually ask for diagnostics at the very beginning of any thread is so there won't be any misunderstandings or miscommunications. Did you turn off parity correction on your parity schedule? You should run a non-correcting parity check now just to confirm the array is in sync and there are no connection or other hardware issues that might cause further problems. Quote Link to comment
Beijergard Posted February 7, 2022 Author Share Posted February 7, 2022 Okay, I should have attached the photos from the start. I havent turned of the parity correction but I will do it now and run a check and see what the results are. I am truly greatful for your respectful answers and your help! Quote Link to comment
Beijergard Posted February 9, 2022 Author Share Posted February 9, 2022 Ok, so now the parity check is done. I unchecked the box for corrections. Is there anything I should or not should do now? plexworm-diagnostics-20220209-0811.zip Quote Link to comment
trurl Posted February 10, 2022 Share Posted February 10, 2022 19 hours ago, Beijergard said: I unchecked the box for corrections. I assume you mean you unchecked the box for correcting on scheduled parity checks. It looks like you ran a correcting parity check manually. I asked for a non-correcting parity check. It looks like it probably was OK this time, but you really should have run a non-correcting check in case there were other problems that might have cause incorrect corrections as discussed. Exactly zero is the only acceptable result for parity sync errors. These may have been caused by working with the disk outside the array. Since these were corrected, and I didn't notice any problems in syslog, I guess you got away with it. You should run a NON-correcting parity check to confirm that you now have exactly zero. Quote Link to comment
Beijergard Posted February 10, 2022 Author Share Posted February 10, 2022 Yes i unchecked the corrections in scheduler, and then I unchecked "write corrections to parity" under main and pressed Check. I don't know how else to run it manually, and it seems strange that it ran corrections even though I unchecked the box? Quote Link to comment
trurl Posted February 10, 2022 Share Posted February 10, 2022 Feb 7 12:20:18 Plexworm kernel: mdcmd (43): check Feb 7 12:20:18 Plexworm kernel: md: recovery thread: check P ... Feb 7 12:42:43 Plexworm kernel: md: recovery thread: P corrected, sector=415890952 Feb 7 12:42:43 Plexworm kernel: md: recovery thread: P corrected, sector=415890992 Feb 7 12:42:43 Plexworm kernel: md: recovery thread: P corrected, sector=415955040 Feb 7 12:42:43 Plexworm kernel: md: recovery thread: P corrected, sector=415955096 Feb 7 12:59:01 Plexworm kernel: md: recovery thread: P corrected, sector=723784352 Feb 7 12:59:01 Plexworm kernel: md: recovery thread: P corrected, sector=723784360 Feb 7 12:59:01 Plexworm kernel: md: recovery thread: P corrected, sector=723784368 Feb 7 12:59:01 Plexworm kernel: md: recovery thread: P corrected, sector=723784376 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737095440 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737133208 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737144424 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737148816 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737155848 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737155872 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737166080 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737166104 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737166120 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737166136 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737215216 Feb 7 12:59:43 Plexworm kernel: md: recovery thread: P corrected, sector=737215224 ... Feb 8 13:57:57 Plexworm kernel: md: sync done. time=92259sec Feb 8 13:57:57 Plexworm kernel: md: recovery thread: exit status: 0 Try rebooting then run a non-correcting parity check. Quote Link to comment
Beijergard Posted February 10, 2022 Author Share Posted February 10, 2022 (edited) Okay, now after reboot the docker service is unable to start. Dont know if it has something to do with me removing the cache drive about one week ago..? Edit, I removed the vDisk for the dockers and reinstalled them again plexworm-diagnostics-20220210-1521.zip Edited February 10, 2022 by Beijergard Quote Link to comment
trurl Posted February 11, 2022 Share Posted February 11, 2022 10 hours ago, Beijergard said: removing the cache drive Why? You want your dockers/VMs (appdata, domains, system shares) on fast pool and not on the array so your dockers/VMs will perform better and not keep array disks spunup since these files are always open. Quote Link to comment
Beijergard Posted February 11, 2022 Author Share Posted February 11, 2022 I had issue with the cache being full and mover doing nothing, scheduled or manually. I have a 128gb nvme, which I initially wanted to use only for dockers, but when I starter using it as cache it got full and never emptied, had to move files with midnight commander and might have messed something up. I also have a 250gb sata ssd, but I dont want to take up any more sata and power cables. So yeah I can but the 128gb back for the dockers. Quote Link to comment
Beijergard Posted February 11, 2022 Author Share Posted February 11, 2022 (edited) Ok, now the second Parity Check is done with corrections unchecked and this time with zero errors. Attaching diagnostics if you want to take a look. Does this mean that all is good now? plexworm-diagnostics-20220211-2215.zip Edited February 11, 2022 by Beijergard Quote Link to comment
trurl Posted February 11, 2022 Share Posted February 11, 2022 14 hours ago, Beijergard said: I had issue with the cache being full and mover doing nothing, scheduled or manually. I have a 128gb nvme, which I initially wanted to use only for dockers, but when I starter using it as cache it got full and never emptied Did you ask for help with that? Probably just some settings wrong. 27 minutes ago, Beijergard said: Does this mean that all is good now? Parity is good Quote Link to comment
Beijergard Posted February 11, 2022 Author Share Posted February 11, 2022 (edited) 11 minutes ago, trurl said: Did you ask for help with that? Probably just some settings wrong. I discussed it with a friend who knows Unraid and Unix a whole lot more than me, and we tried this. I only have two dockers, some plugins but no VMs, so I think I will put the 128 nvme back in and start using it again. Just have to figure out how to put the appdata and dockers on the ssd.. Edit, I just freed up a 480GB Nvme from my gaming PC, I will put it in the Unraid server tomorrow, then I can use the disk as a cache aswell, 128GB isnt quite enough I believe. Edited February 11, 2022 by Beijergard Quote Link to comment
trurl Posted February 11, 2022 Share Posted February 11, 2022 Set appdata and system shares to cache prefer, disable Docker in Settings, run mover 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.