trurl

If you have an adblocker whitelist your server.

It will rebuild the disk from parity. That is what is required because the disk is not in sync. Unraid disables a disk when a write to it fails. After a disk is disabled, Unraid does not use it again until rebuilt. Instead, it emulates the disk from the parity calculation using parity and all the other disks. Emulation includes writing. That initial failed write, and any subsequent writes to that disk, updates parity, so those writes can still be recovered by rebuilding the disk. Just assign the disk and start the array to begin rebuild.

OK. Just trying to confirm that your last parity check had errors. You must run a correcting parity check to correct those. And then run a non-correcting parity check to confirm you don't still have any. Exactly zero sync errors is the only acceptable result and until you get that result you aren't finished fixing things.

Plex and many other apps run as dockers

Emulated disk3 is mounted so rebuild should be OK. Is unassigned disk sdf serial ending 6SLT the disk that should be assigned as disk3?

Disk is unmountable but not disabled, SMART looks OK. Rebuild is not the solution to unmountable. You must repair the filesystem: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Be sure to capture the results so you can post them.

You must configure Notifications to alert you immediately by email or other agent as soon as a problem is detected. Don't let one unnoticed problem become multiple problems and data loss.

I am in favor of not autostart if a disk is disabled or missing, but see my replies on your other thread about why you must rebuild anyway.

No it is still out-of-sync. Unraid disables a disk when a write to it fails. After a disk is disabled, Unraid does not use it again until rebuilt (or new config as mentioned). Instead, it emulates the disk from the parity calculation using parity and all the other disks. Emulation includes writing. That initial failed write, and any subsequent writes to that disk, updates parity, so those writes can still be recovered by rebuilding the disk. Has absolutely nothing to do with autostart since it is already out-of-sync as soon as it is disabled. If you did New Config without rebuilding parity, then your array is out-of-sync. You must do a correcting parity check to get it back in sync. And then you should do a non-correcting parity check to verify that you have no sync errors. Exactly zero sync errors is the only acceptable result and you aren't finished fixing things until you get that result.

Rebuilding is required because the disabled disk is out-of-sync with the array. Just enabling it without rebuilding will not fix the out-of-sync. The only other possibility is to rebuild parity instead so everything is back in sync, but since it is the disabled disk that is out-of-sync it usually makes more sense to rebuild it.

unBALANCE is about disks, mover is about user shares. unBALANCE moves from specified disks in the array to other specified disks in the array. Mover moves user share files from cache to array or array to cache based entirely on the settings of each user share. Each user share's settings controls which disk the files wind up on.

That diagnostic is without the array started so can't tell anything about the emulated disk3. Start the array and post a new diagnostic.

Go into your BIOS and set SATA controller to AHCI (currently using IDE mode) and try rebuild again

Parity is not a substitute for backups, whether Unraid or any traditional RAID. All parity allows you to do is rebuild a missing disk. Other reasons for data loss are much more common than failed disks, including user error. It's not a question of disabling trim for array disks because it is not enabled. It is simply a fact that SSDs in the array cannot be trimmed.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread. These words do not belong together and suggests you are considering making a VERY BIG mistake. Don't do anything without further advice.

Are you referring to the fact that parity and disk1 are disabled? They are being emulated until rebuilt. Looks like emulated disk1 is mounted so that's good, and since you have dual parity you can rebuild both. Since you rebooted nothing in syslog from when the problem occurred. No amount of messing with the hardware will re-enable a disk.

Don't understand what you mean by "without parity". Parity disk seems to be OK and not disabled. If you corrected parity errors you must run another parity check to verify. Exactly zero parity errors is the only acceptable result and if you didn't get that on your last parity check you aren't finished. See if there is anything useful for you in this thread:

Unless you have some specific reason to suspect a specific data disk, such as immediately after a data disk rebuild, you have no choice but to correct parity.

One more bit of encouraging information, though not sure it definitively answers the questions. From the diagnostics emulated disk3 is mounted, so that would seem to indicate that rebuilding disk3 from parity should be successful.

And also no reason to remove unless you intend to replace it with a different disk. Still trying to decide whether or not to believe in parity or not. I filtered out a lot of that. So the scheduled parity check was configured to write corrections to parity. Did you let it complete? Apparently you rebooted after that scheduled parity check Oct 1 22:48:06 baconator kernel: Linux version 4.19.107-Unraid (root@38721b48cdfb) (gcc version 9.2.0 (GCC)) #1 SMP Sun Mar 8 14:34:03 CDT 2020 no indication of an unclean shutdown, but another parity check started soon after the reboot. Oct 1 22:50:58 baconator kernel: mdcmd (45): check Oct 1 22:50:58 baconator kernel: md: recovery thread: check P ... Did you do start that one? Was it also a correcting check? Or was it actually rebuilding parity? Still ongoing 9+ hours later Oct 2 08:00:01 baconator root: Parity Check / rebuild in progress. Not running mover Then lots of read errors on disk3, finally the write errors that disabled it. Possibly Unraid tried to write the calculated data back to the disk it couldn't read. And finally it stopped itself. Oct 2 12:48:51 baconator kernel: md: disk3 read error, sector=10938752032 Oct 2 12:48:51 baconator kernel: md: disk3 write error, sector=15780546472 ... Oct 2 12:49:27 baconator kernel: md: recovery thread: exit status: -4 My inclination at this point is to not believe in parity, but instead do New Config, and rebuild parity instead of rebuilding disk3. After you have fixed your hardware, of course. The main problem with that idea would be if disk3 was corrupted somewhere along the way but that should become apparent immediately when starting the array. Or you could New Config without parity initially just to check if disk3 mounts, but not sure there would be much point since parity would definitely be out-of-sync that way. If there was disk3 corruption that could be dealt with separately. The SAFEST approach would be to rebuild disk3 to a new disk and save the original disk3 and decide later which version of disk3 looked the best. Of course, that would require another disk. See if there is anything else you would like to add, and maybe wait to see if someone else has a different opinion or approach.

Yes

You did mention that. Removing and formatting is totally unnecessary. Formatting outside the array would be totally pointless before using the disk for rebuild since rebuild would completely overwrite the disk regardless of how it was formatted. In Settings - Scheduler - Parity Check, there is an option to write corrections during the scheduled check or not. The usual recommendation is No. Check that setting and let us know and also what time the check is scheduled to start. I'm trying to sort through syslog to see but a lot of nvidia related spam in there.