trurl

Since the only pool you have is unmountable, there is nothing mover can do. Might as well stop it. Disable Docker and VM Manager in Settings until you get cache working again. They have already created new files on the array that you will need to clean up later. Why do you have docker.img set to 100G?

Might be a good idea to post diagnostics in case there is something you have overlooked or haven't told us about.

For future reference, normally you would and if that looked good, rebuild. Since you repaired the disk outside the array, it is out-of-sync, so the only way to get it back into the array is

Probably anything corrupt won't copy anyway but you can try before going on to... Check filesystem on disk2 from the webUI without -n. If it asks for it use -L. Capture the output and post it.

Attach Diagnostics to your NEXT post in this thread.

I don't bother with split level. Default High-water Allocation will usually result in files that are written together going to the same disk anyway, and if they do get split, the only penalty is a delay for another disk to spin up when accessing the files. Minimum Free should be set larger than the largest file you expect to write to the share. If you set it to zero, it will calculate a value that probably isn't what you need. That is to prevent you from overfilling a disk, but can also result in not allowing the disk to be written anymore when it still has enough space. If a disk has less than Minimum Free, Unraid will choose another when it begins to write a file. But Split Level has precedence, so if that says a file belongs with other files, that is where it will try to put them even if it doesn't have Minimum Free.

All your array data disks are mounted and no I/O errors logged. Your docker.img has corruption so you will probably have to recreate and reinstall, but that isn't related to parity. Since parity has none of your data, might as well let it finish correcting sync errors.

Do you have another copy of anything important and irreplaceable?

Is this assigned to the array? SSDs in the array cannot be trimmed.

UPS should only be on battery long enough to get past brief outage, then if power doesn't come back very soon, shutdown. You don't want to run on UPS, only shutdown on UPS.

Those small laptop HDDs probably don't perform well. And your parity disk is SMR which might be the reason a pause helps it out.

syslog says it is correcting, but I think unclean shutdown parity check is supposed to be non-correcting. I don't know if plugin affects that or not. Seems like more sync errors than I would expect from unclean shutdown. Were previous parity checks zero sync errors?

Check filesystem on disk2 from the webUI. Capture the output and post it.

First post in thread 😉

Probably because of your split level setting

I see that setting now.

What does this refer to? Doesn't seem to be anything related to the Unraid OS itself. If you are asking about a docker container you should go to its support thread or page. You can usually get there by clicking its icon in your Unraid webUI and selecting Support. For future reference

You're right, it only lets me set it to a user share path. Which is probably better anyway since UD devices may not be mounted. And in the more general case where you are really sending syslog to a remote server, it has to be a shared path. Does it work with both NFS and SMB? Or does it do it some other way?

You should be able to see your CPU temps in the BIOS. And Dynamix System Temps plugin shows this for me in Unraid.

The flash drive is the only device that is guaranteed to exist. You can configure syslog server to use a path on an Unassigned Device with the other settings, but flash is the only thing that makes sense for "mirror" since it doesn't require you to set any path.

Not clear there is anything wrong with disk1, and replacing/rebuilding it won't fix its filesystem.

Probably better to start a new thread with your diagnostics than post to a 5 year old thread about a version you don't have.

I often recommend not even using parity with USB since if something disconnects, the array won't be out-of-sync since there is nothing to be in-sync with. So nothing to rebuild. But nothing can be rebuilt.

Each data disk in the Unraid array is an independent filesystem that can be read all by itself on any Linux. You could just New Config disk7 back into the array and rebuild both parity. Maybe physical disk7 is actually mountable and not corrupted. And then live with whatever results from repairing disk1 and possibly disk7 (until the next time). Even if parity rebuild won't succeed, parity contains none of your data as mentioned. Your earlier diagnostics seemed to indicate there was a lost+found share, which would have been the result of an earlier check filesystem. It doesn't show as currently existing, possibly it is on the unmountable disk7 so can't be seen until repaired (again).