trurl

Any time a disk is disabled or missing, Unraid emulates it from parity plus all other disks. Emulated doesn't actually refer to any physical disk, it is just the contents of the disk slot as calculated from parity.
 
Usually, when we talk about "repair", we mean repairing a corrupt filesystem. Any time a disk that should have data on it is "unmountable", it needs filesystem repair. What you probably mean by "repair" should be referred to as rebuild. A disk is mounted when the OS loads its filesystem to allow access.
 
Rebuilding to a different disk does leave more options, but those options aren't usually needed when the emulated disk is mountable. If the emulated disk is unmountable, the results of attempting filesystem repair may not be as good as the contents of the original disk.
 
The only way to return the original disk after attempting a rebuild to a different disk would be to New Config with the original instead of the replacement, and rebuild parity.

If you did want this feature, they would have to be reformatted to btrfs or zfs since xfs doesn't support multidisk pools.

Not seeing that card in lspci, only the realtek on the mobo

Nothing can move open files.
 
Disable Docker and VM Manager in Settings.
 
Set appdata, domains, and system shares to Primary:nvme; Secondary;array; Mover action:array->nvme
 
Run mover, wait for it to complete, post new diagnostics.
 

Set downloads share to
Primary:cache_nvme; Secondary:array; Mover action:cache_nvme->array.
After we get that one moved we can change it so it only puts files on the array.
 
Set appdata, domains, isos, system shares to
Primary:cache_nvme; Secondary:array; Mover action:array->cache_nvme.
 
What do you get from command line with this?
du -h -d 1 /mnt/cache_nvme And this?
du -h -d 1 /mnt/disk1  
Also post new diagnostics after completing those steps.

You can include the new disk in the new config, and format it during or after parity build.

https://docs.unraid.net/unraid-os/manual/shares/user-shares/#high-water-method
 
This is the default for good reason. It is a good compromise between using all disks eventually, without constantly switching between disks. It allows other disks to spin down, and usually keeps files that are saved together on the same drive, so they can be accessed together without having to spin up other disks.

Are you writing to a cached share? Screenshot looks like you are writing directly to the array.
https://docs.unraid.net/unraid-os/manual/storage-management/#array-write-modes
 
Shares are not cached by default, you have to set that up for each share individually.
https://docs.unraid.net/unraid-os/manual/shares/user-shares/#primary-and-secondary-storage-unraid-612
 
If you need to write more at one time than cache can hold, don't cache.
 
For initial data load, going without parity until initial load is complete will be faster, then build parity when done with initial load.

Looks good!
 

Not clear what you think the distinction is.
 
Disk 1 isn't changed when writing to disk2, so it isn't involved in updating parity.
 
https://docs.unraid.net/unraid-os/manual/storage-management/#array-write-modes

Anything you installed yourself from docker hub or elsewhere will have a template if you installed it from the Add Container page.
 
I've never used compose.

It complicated management, since it means you have to make sure none of your containers are configured to use the default appdata share. Some templates are sloppy and assume appdata instead of the path in docker.cfg
 
And leave it uninstalled at least until everything is working as it should be. I really recommend not using that plugin at all. Why do you think you need it?

Mar 24 03:01:02 Prodesk kernel: sd 9:0:0:0: attempting task abort!scmd(0x00000000bb3cabf6), outstanding for 15349 ms & timeout 15000 ms Mar 24 03:01:02 Prodesk kernel: sd 9:0:0:0: [sde] tag#854 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Mar 24 03:01:02 Prodesk kernel: scsi target9:0:0: handle(0x0009), sas_address(0x4433221100000000), phy(0) Mar 24 03:01:02 Prodesk kernel: scsi target9:0:0: enclosure logical id(0x5c81f660f54f7000), slot(3) Mar 24 03:01:06 Prodesk kernel: sd 9:0:0:0: task abort: SUCCESS scmd(0x00000000bb3cabf6) Mar 24 03:01:06 Prodesk kernel: sd 9:0:0:0: [sde] tag#867 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=19s Mar 24 03:01:06 Prodesk kernel: sd 9:0:0:0: [sde] tag#867 Sense Key : 0x2 [current] Mar 24 03:01:06 Prodesk kernel: sd 9:0:0:0: [sde] tag#867 ASC=0x4 ASCQ=0x0 Mar 24 03:01:06 Prodesk kernel: sd 9:0:0:0: [sde] tag#867 CDB: opcode=0x8a 8a 08 00 00 00 04 00 15 c3 68 00 00 00 08 00 00 Mar 24 03:01:06 Prodesk kernel: I/O error, dev sde, sector 17181295464 op 0x1:(WRITE) flags 0x20800 phys_seg 1 prio class 0 Mar 24 03:01:06 Prodesk kernel: md: disk4 write error, sector=17181295400 Several days since it became disabled, and of course, no further attempts to access a disabled disk. Looks like a problem communicating with the disk, cable connection, etc.
 
Filesystem Size Used Avail Use% Mounted on /dev/md4p1 17T 9.7T 6.7T 60% /mnt/disk4 emulated disk4 is mounted
 
After checking/fixing connection, etc.

No, I'm thinking something with the mobo is rebooting, not related to Unraid. If it was just Unraid unresponsive, it would just sit there until you rebooted.

Looks like a bad connection. Check connections, SATA and power, both ends, including splitters.

Here I quote the only part of that thread you need to consider:
  
 

Get Diagnostics after reboot. That will tell about your hardware and configuration. 
 
Then setup syslog server. That will tell what's happening. 
 
Also, this command while things are starting to go bad might tell.
 
df -h /  

USB enclosure could complicate things so if you can plug them in directly in your server that would be ideal.
 
Parity won't be mountable because it has no filesystem.
 
Others should mount with Unassigned Devices, unless they need filesystem repair, which can also be done as Unassigned Devices.
 
Any idea what filesystem they should be?

None of the .old files are used. You have multiple .key files, you only need Pro
 
You should use the stock go file.
 
I can imagine vfio-pci.cfg causing problems, you might consider removing it completely for now.

https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares
Ideally, the "default" shares should have all files on cache or some other pool, with no files on disk1 or any other array disks, so Docker/VM performance will not be impacted by slower array reads and especially writes, and so array disks can spin down since these files are always open.
 
Nothing can move open files, so to work on this, you need to go to Settings - Docker and disable that, and go to Settings - VM Manager and disable that.
 
Set each of the default shares to
Primary:cache; Secondary:array; Mover action:array->cache
 
Run mover, wait for it to complete, post new diagnostics.

ethtool says no link detected. Those earlier diagnostics didn't even have any ethtool output.
 
You could check cables, ports, etc.
 
You have this realtek, a sometimes problematic brand with linux
85:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 0c) Subsystem: ASUSTeK Computer Inc. Device [1043:88e1] Kernel modules: r8169 There is a driver plugin for that in Apps, but would be difficult to install with no internet working.
 
Do you have another adapter you could try?

All spinners in the array, no SSDs or nvme in the array. Parity must be at least as large as the largest array data disk, so 18TB parity.
 
Since the SSDs are different sizes I would put those in different pools, maybe the 4TB as cache.
 
nvme, another pool, would be good for the "default" shares that support Dockers/VMs
https://docs.unraid.net/unraid-os/manual/shares/user-shares/#default-shares

Browse into the flash drive and delete config/shares/share_name.cfg then make its settings again.

Apr 6 21:28:07 unraid root: Fix Common Problems: Error: Invalid folder cache contained within /mnt This is likely to be the cause of problems, looks like you probably renamed one of your pools, but still have a path specifying /mnt/cache somewhere. Probably a container host volume.
 
Since /mnt/cache isn't mounted storage now, it is a path in RAM, which obviously will not persist after reboot.

I didn't notice any I/O errors, so the disks probably really do have unmountable filesystems.
Stop the rebuild.
 
Start with disk5, check filesystem on disk5 from the webUI, post the output.