trurl

Should have finished in a few minutes at most. Post new diagnostics.

/mnt/cache contains only what is on cache, /mnt/disk1 contains only what is on disk1, etc. /mnt/user contains all user shares. User shares span all array disks and all pools.

Rebuild won't delete any files because parity doesn't know anything at all about files. A missing/disabled/failed disk is emulated from the parity calculation by reading all other disks. https://wiki.unraid.net/Manual/Overview#Parity-Protected_Array Rebuild will simply write that emulated data to the disk. Whatever you have now on the emulated disk is what you will get by rebuilding it. Maybe the missing data was on cache. Cache is not part of the parity array and can't be rebuilt from parity. Cache is not currently assigned, but earlier you said it was unmountable. If your missing data was on cache, you would have to recover data from that cache drive if you could get it to work.

No. We are doing this so the new 8TB disk will be an empty xfs filesystem. The original files are still on disk5 in this new configuration. Then we can copy files from a reiser disk to this empty new 8TB disk and those copies will be files on an xfs filesystem. When we have completely copied all files from one of the reiser disks, we can reformat it and it will become an empty xfs filesystem ready to receive copies from other reiser disks so they can be reformatted. Repeat as necessary until all array disks have been reformatted xfs. At some point we will be able to shrink the array after copying all data from one of those reiser disks, then cache can go back in. I see from previous diagnostics it is already xfs so we are good there.

SSDs in the parity array cannot be trimmed, and can only be written at parity speed. But, disks outside the array have no parity protection. What might make more sense is a 2 SSD btrfs raid1 mirror as cache, of whatever size needed to cache user share writes plus extra for things that need speed. appdata, domains, system shares are typically kept on fast pool so Docker/VM performance isn't impacted by slower array, and so array disks can spin down since these files are always open. Since this would be a mirror, the total capacity would be equal to the smaller disks. Best if they are the same size. Good time to start thinking about backup too. Parity and mirrors are not a substitute as you have seen. You don't have to backup everything, but you must always have another copy of anything important and irreplaceable.

Do you have a current backup of flash for this server? Unrelated, but your appdata, domains, system shares are on the array. Ideally, these would be all on fast pool and set to stay there so Docker/VM performance isn't impacted by slower parity, and so array disks can spin down since these files are always open. What is the purpose of the 2 shares you have cache:only? Also segfaults from guacd, I assume a docker.

You must always have a current backup of flash.

The templates are exactly the entries from the Create/Edit Container page.

Not the full story of how it works. Your docker.img is on your data storage somewhere, and that contains the container executables. Your appdata is on your storage somewhere, and that is where each application has its working storage (settings, etc.) So, if you have all that, the dockers will run, but without those templates from flash, the webUI doesn't know how to work with them.

FTFY

Your appdata has files on the array. That is the main one that you probably should be directly mapping to cache. You need to get that all on cache for that to work across the board. Your other mappings, for example, means that when plex accesses /movies, all it will see are those that are on cache. I assume that isn't what you want, since it looks like your Movies share has files on lots of other disks.

A few things I would change about the way you are probably thinking, but the real question is where the cam is storing. Any writes to the parity array must also write parity so at least 2 disks spun

I help people with that all the time, not very difficult.

Why do you think you want a clean install anyway? Unraid is already a "clean install" at each boot. The OS is unpacked fresh from archives on flash, into RAM, at each boot, and it runs completely in RAM. Think of it as firmware. These OS archives on flash are never changed by anything you do with your server, except they are replaced when a new release is installed. All of your configuration (settings from the webUI including disk assignments) are stored in the config folder of flash so they can be reapplied at boot.