trurl

Are there any symptoms while it is running? Are you sure there isn't a power issue?

no invalidslot might be the more direct way to do it all at once instead of trusting parity first, then replacing. But, invalidslot requires overriding the webUI from the command line at one point in the process. Let us know when you get the replacement and we'll see if we can reach consensus.

Not sure if you know it but you will always get a parity check after an "unclean shutdown". Is it actually rebooting, or is it just unresponsive and you are rebooting it yourself? Try disabling the docker service (Settings - Docker) and VM service (Settings - VM Manager), reboot in SAFE mode, and see if it will complete a parity check.

Does it run stable if you disable VMs and Dockers? Why do you have 60G allocated to docker.img, have you had problems filling it? 20G should be more than enough, and making it larger won't fix anything, it will only make it take longer to fill.

That suggests you still had some problem with the disk or its connections. Couldn't have anything to do with preclear because

Did you find this in the FAQ pinned near the top of this same subforum?

Much easier to add another SSD later than to upgrade CPU/mobo Any good brand name between 4GB and 32GB, USB2 is all that's needed and often more reliable than USB3.

I've never considered size of array and size of cache to have any obvious or necessary relationship. Lots of different ways to use cache. Most will have some things (dockers, VMs) staying on cache.

You haven't yet been able to convince your BIOS to boot from the Flash. Try another.

Parity is not a substitute for backups. And I wouldn't trust my array to USB parity in any case. Whether or not it is acceptable to have SSDs in the parity array I will let others comment on. I know there has been some discussion about whether some SSDs might actually invalidate parity. SSDs in an array without parity would be fine, except they can't be trimmed. An array without parity that included some USB connections would be fine since there is nothing to keep in sync so nothing to be disabled if a disk is dropped. Don't be surprised if you have that USB parity disconnect and require frequent rebuilds. And of course there is the write speed penalty. Do you know that any write to an array disk must also write parity? And parity updates are actually slower than the slowest disk involved. So write speed to those SSDs will be slower than that USB HDD parity disk.

yes

Diagnostics would be a way to confirm. That may not solve the problem. Be sure to boot from USB2 port.

You will probably have to get your controller issues resolved before you can make any progress.

/boot is your flash drive. Sounds like you may have a problem with flash. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Why would invalidslot be needed to rebuild disk14 if it is replaced with a new disk? Wouldn't trust parity be good enough?

It is possible to try to mount them outside the array, but that would technically invalidate parity at least a little. I think another possibility would be to clone them outside the array and see if the cloned disks are mountable, but that would require spare disks and would be time-consuming. Perhaps the simplest, and possibly as good as any other way, would be trusting the array, rebuilding disk14 to a new disk, and then repairing the corruption, if any really exists, on the other disks.

Almost impossible to lose everything since each disk is an independent filesystem. Currently, only the 3 disks in question are at risk, and chances of recovery seem very good.

We don't know that the physical disks 6 and 19 have unmountable filesystems, because those physical disks have not been read since they became disabled. Instead, those disabled disks are emulated by reading all other disks and getting the data for the disabled disks from the parity calculation. So, the failing disk14 is providing some of the bits for the emulation of the disabled disks. It is the emulated disks that are unmountable.

Not entirely sure I understand what you are saying in this post. You must rebuild a disabled disk, whether the disabled disk is parity or data. There is no need to clear a disk you are going to rebuild, because the rebuild will completely overwrite the disk anyway. Are you saying that you had to clear the disk again before it would let you rebuild? That is the part I am not sure I understand. The correct procedure to rebuild to the same disk, whether parity or data Stop array Unassign disabled disk Start array with disabled disk unassigned Stop array Reassign disabled disk Start array to begin rebuild

So you have an external HDD connected by USB as parity, and all your array disks are SSDs? Seems like a number of bad ideas combined into one design.

Could be failing disk14 is actually the cause of the unmountable filesystem on the emulated disks. Maybe the best way forward would be to New Config / Trust Parity and then try to replace / rebuild disk14 and if there really is corruption on the other disks try to repair after that. The main thing that troubles me with making that recommendation though is that I don't know why those other disks became disabled. The syslog in those first diagnostics you posted may have a clue since they probably cover those events, but it was quite a lot of stuff that I haven't seen before. I am going to ask @johnnie.black for a second opinion.

have you done memtest?

What exactly is the "it" in this statement?

Unraid installs itself into RAM fresh from the archives on Flash at each boot. Think of it as firmware except easier to work with.

Are the other 2 disks still testing?