trurl

emulated disk2 is mounted.
 
And empty or mostly so. Apparently that is expected.
 
Highwater allocation will write disk1 first which is expected and perfectly fine. Highwater is the default and the preferred allocation for most situations.
 
Not sure why disk3 seems to have slightly more data than disk2, possibly include/exclude share setting, or maybe writes directly to the disk instead of to a user share.
 
You can see how much of each disk is used by each user share by going to the User Shares page and clicking Compute All button at bottom. It might be useful to see a screenshot of that to get a better idea how your shares are working.
 
Oct 17 12:45:12 HomeNAS-unRAID root: Fix Common Problems: Warning: NerdPack.plg Not Compatible with Unraid version 6.11.1 NerdPack is deprecated on 6.11. Uninstall and get the new NerdTools plugin.
 
You should definitely replace disk2. Be careful with connections. Then rebuild should be OK.

No it doesn't make any sense at all. All of parity is always used, it is always completely full of parity bits. Doesn't matter at all how much space is used on any of your data disks. Parity contains none of your data, it is just parity bits that allows a missing disk to be calculated from parity and all the other array disks.
 
This is basically the way parity always works wherever it is used in computers and communications. Other conventional RAID systems stripe parity and data across the array but parity is still just an extra bit that allows a missing bit to be calculated from all the other bits. With Unraid, parity is all on one disk, and each data disk is an independent filesystem that can be read all by itself. This allows mixed size disks to be used in the array and allows disks that haven't failed to still be read even if too many other disks have failed, unlike conventional RAID.
 
In the special case where there is only a single data disk, parity is effectively a mirror since that is just how the calculation comes out. But in that case if the single data disk was encrypted, so would the mirror be.
 
https://wiki.unraid.net/Manual/Overview#Parity-Protected_Array
 
 

Looks like rebuild had only been going for a few minutes when diagnostics were taken. Let it run a while and get new diagnostics if speed doesn't improve.
 
How have you managed to use 87G of 150G docker.img? 20G img is often more than enough. And never seen anyone need more than default 1G libvirt.img.
 
The usual reason for filling docker.img is an application writing to a path that isn't mapped.
 
 

On User Shares page, click Compute All button at bottom, wait for complete results, post screenshot

You can have multiple pools outside the parity array, 'cache' is the traditional pool like this, but you can have others named as you wish. You don't even have to have a pool named 'cache'. Each pool can have multiple disks if it uses btrfs raid. All pools are part of user shares.

plugins
NerdPack.plg - 2021.08.11 (Up to date) (Incompatible) Looks like you were installing every package. Do you even know what most of that is for?
 
There is a new NerdTools plugin, I recommend not installing anything you don't use frequently.

Maybe you already acknowledged it. Or maybe you aren't looking in the right place. Post a screenshot
 
One thing you are doing wrong is having scheduled parity check set to correct parity errors. You don't want to corrupt parity if another disk or other problem such as bad RAM is causing parity errors. You should set the scheduled check to NOT correct parity, and then if there are parity errors, you can decide whether to correct them by running another parity check.
 
Let extended SMART test complete. If it is OK should be alright to rebuild to the same disk.
 
Do you have another copy of anything important and irreplaceable? Parity is not a substitute for backups

OOM seems VM related.
 
Why do you have so much DHCP going on in syslog? What are you using for router?
 
You didn't mention it for some reason, but disk2 has disconnected and is disabled. Emulated disk2 is mounted though.
 
Not much data on any of your disks yet. I assume that is expected.
 
Shut down, check connections, SATA and power, both ends, including splitters. Boot up, start the array, post new diagnostics.
 
 
 
 

All the FSCK files on flash are from correcting filesystem corruption on flash, so that is probably what happened to your ident.cfg and maybe some other things. Do you have a current flash backup?

You can have multiple pools outside the parity array. Cache was the original pool outside the array. Now you can have additional pools, named as you wish. You don't even have to have one named 'cache' if you don't want. A pool can have multiple disks if it uses btrfs raid. Pools, like original cache, are still part of user shares. Each user share has settings that control which pool it uses and how.
 
Many of us do exactly what you want to do, with SSDs in a pool and HDDs in the parity array.

Suspect this has something to do with your removing pool 'cache' and creating pool 'warm-storage'. What more can you tell us about that?
 
The slots for 'cache' still exist and 'cache' is still showing in btrfs-usage so that doesn't seem right, but I will have to get @JorgeB to comment on that.
 
On your flash drive, in config/shares folder, you have .cfg files for domains, isos, and system, and they all designate the 'cache' pool instead of 'warm-storage'. Maybe you will have to delete those .cfg
 
 

Those shares (appdata, domains, system) are set to prefer cache, which means keep them on cache and if any are on the array, move them to cache.
 
And that is how you want those shares. You don't want them moved to the array.
 
If those shares are on the array, docker/VM performance will be impacted by slower array, and array disks can't spindown because these files are always open.
 

2 - 3 hours per TB of parity is reasonable.
 
No I/O errors in syslog yet.
 
Do any of your disks have SMART warnings on the Dashboard page?

If your appdata, domains, system shares are on the array, then your dockers/VMs will keep disks spunup since these files are always open.

Diagnostics already includes SMART for all attached disks so no need to attach it separately.
 
SMART for new disk looks fine. I guess we can let rebuild test the disk and its connections.
 
Follow these instructions carefully. If things don't seem to work as described, or you have questions, let us know. We will check some things along the way to see how well things are working.
Go to Tools - Diagnostics, Retain All, Apply Reassign disk1, assign new disk as disk2 Check BOTH parity valid box AND maintenance mode box Then start the array and post new diagnostics and a screenshot of Array Devices
 
Those steps will get disk1 back into the array, a new disk in disk2 slot, all other disks as is, and without actually mounting anything so parity and all disks are unchanged.
 
The next steps (after we get diagnostics and screenshot) will disable disk2 so it can be rebuilt on the new disk.

Emulated disk12 is mounted so repair shouldn't be necessary. SMART for both disabled disks looks OK though neither have had extended SMART tests done.
 
Since you rebooted before getting diagnostics syslog reset so can't see what might have caused them to become disabled.
 
https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself
 
With dual parity you can rebuild 2 drives at once.

As you can see, emulated disk5 is mounted and has 531G contents. You can examine those emulated contents if you want. They are exactly what would be rebuilt.
 
To rebuild, stop array assign disk5, start array to begin rebuild.

Looks OK. On the Dashboard page, you can click on the SMART warning for the disk to acknowledge it and it will warn again if it increases.

As long as you don't change any disk assignments.

Parity errors could go to millions if someone is checking invalid parity, for example, filling log space and then nothing could be logged. The lines it does log should be enough for you to see what you need.
 
Looks like you are having connection problems on disk15. I recommend dual parity with so many disks.
 

Any folder at the top level of array or pool disks is automatically a user share. Any folder at the top level of /mnt/user is also a user share, and will be created on an array disk if it doesn't already exist as a user share. Any user share will have default settings (cache:no, for example) until you set them.

Parity contains none of your data and by itself can recover nothing. Parity is basically the same concept wherever it is used in computers and communications. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits. Parity disk allows a missing disk to be calculated from all the other disks.
 
https://wiki.unraid.net/Manual/Overview#Parity-Protected_Array
 
Note that all other disks are important in recovering a failed disk. This makes me concerned that you are considering using some old, small disks of questionable health in your array.