trurl

Not exactly the same thing you were asking about, but in case you don't know. it is possible to pause and resume parity as long as you don't stop the array or reboot. There is also a plugin that lets you schedule this so you can do parity checks in smaller chunks.

Here is how this whole disable and emulation thing works. When a write to a disk fails, Unraid disables the disk. If the disk is a data disk, the write is still used to update parity. So that failed write can be recovered when the disabled disk is rebuilt. The disk is disabled because it is no longer in sync with parity. After a disk is disabled, the actual disk is not used again until it is rebuilt (or in your case, a New Config, see below). Instead, the disk is emulated by reading all other disks to get its data. The emulated disk can be read, and it can also be written by updating parity. So writes to the emulated disk continue even when the disk is disabled. Those writes can be recovered by rebuilding the disk from the parity calculation. And, rebuilding the disk is the usual way to recover from this, because the disk is no longer in sync with parity, since parity contains writes that happened with the disk disabled. It is also possible to enable all disks again by setting a New Config and rebuilding parity, thus getting parity back in sync with all the data disks in the array. But any writes to that disk that happened with the disk disabled are lost when you take that option. In your case, the actually failing disk14 was contributing bad data to the emulation of those disabled disks. That resulted in those emulated disks being unmountable. But the actual disks were still mountable, as we discovered. Technically, parity is out-of-sync with those disks, but maybe not much. The rebuild of disk14 is relying on that "not much". One final note. If a read from a disk fails, Unraid will try to get its data from the parity calculation by reading all the other disks, and then try to write that data back to the disk. If that write fails the disk is disabled. So, it is possible for a failed read to cause a failed write that disables the disk.

A drive failing can cause bad writes to that drive certainly. Writes to one drive are unrelated to writes to other drives since each disk is an independent filesystem. Except of course that parity is always updated when a data drive is written, but even there, parity is only disabled when a write to parity fails. Do you really know it was "within just a few moments"? If you know exactly when these events occurred that would point to where in your syslog to look for them.

Reviewing your diagnostics, I think I must have been referring to the fact that you have allocated 80G to docker.img, and are using 26G of that. My usual recommendation is only 20G allocated for docker.img. Anytime I see someone with more than that it makes me wonder if they don't have some application writing to a path that isn't mapped. I have 20G allocated to docker.img. I am running 17 dockers, and they are using less than half of that 20G. Have you had problems filling docker.img? Making it larger will not fix anything, it will only make it take longer to fill. The usual reason for using more space than necessary in docker.img is for an application to write data into the docker.img. That will happen when it writes to a path that isn't mapped to host storage. Common mistakes are writing to a path that doesn't exactly match the mapped container path with regard to upper/lower case, or writing to a relative path (what is it relative to?)

These things are unrelated. Unraid disables a disk when a write to it fails. Simple as that.

Some SMART attributes are more serious than others. Which one was it that you acknowledged?

Don't know if this is related: Aug 26 18:50:02 Acu-Tower vsftpd[25980]: connect from 184.105.139.70 (184.105.139.70) Aug 26 19:42:34 Acu-Tower vsftpd[7115]: connect from 170.130.187.58 (170.130.187.58) Aug 26 20:00:51 Acu-Tower vsftpd[23429]: connect from 192.241.227.131 (192.241.227.131) ... Aug 26 22:18:44 Acu-Tower vsftpd[16593]: connect from 104.152.52.34 (104.152.52.34) ... Aug 27 01:51:23 Acu-Tower vsftpd[16342]: connect from 91.241.19.109 (91.241.19.109) https://www.abuseipdb.com/check/184.105.139.70 https://www.abuseipdb.com/check/170.130.187.58 https://www.abuseipdb.com/check/192.241.227.131 https://www.abuseipdb.com/check/104.152.52.34 https://www.abuseipdb.com/check/91.241.19.109 And lots more like that.

Normally, when you New Config, parity is rebuilt by default. You don't want to rebuild parity, you want to use existing parity to rebuild disk14 instead. Invalidslot lets you specify a different disk to rebuild during New Config.

yes, according to page 24 of the manual (VT-d) https://download.gigabyte.com/FileList/Manual/mb_manual_b460m-ds3h-ac_e_1003_v2.pdf

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.