trurl

Parity is realtime, cache is not. In fact, there is no requirement for cache to get flushed to the array. Cache is just additional (and differently managed) storage. One of the features of Unraid is the Mover, which will move files from cache to array for those shares set to cache-yes, and it can even move files from array to cache for those shares set to cache-prefer. Or Mover will ignore files for cache-no or cache-only shares. Mover runs on schedule, default is daily in the middle of the night. It is typical to set things up so some things stay on faster cache, such as dockers and VMs. Files for a user share on cache are part of the user share just as files on the array are. Files typically will not exist on cache and array at the same time, though you could force this by working directly with the disks, in which case, files on cache have priority when accessing the user share. Here are some more details about the various cache settings for each user share:

And no doubt was used in that video.

Various btrfs raid configurations are available in the pool(s).

Just trying to see if something about one of your plugins might be causing this.

No, it is a unique identifier, often referred to as the GUID. It is built in to the USB drive and is unique to that specific USB drive. Or, at least, it is required to be unique in order to have an Unraid license associated with it. If you were able to get a license then it must be OK.

I am running latest beta, so I have 2x500GB SSD as cache pool, and 256GB NVMe as "fast" pool.

Due to parity updates, it will always be slower than single disk speed for writing to the array. Same as single disk speed for reading from the array. But, since each disk is an independent filesystem, each disk can be read independently on any linux. If you lose more disks than parity can recover, you haven't lost everything as in RAID. Also, since each disk is an independent filesystem, you can mix different sized disks in the array, and easily add disks without rebuilding the array, and easily replace disks with larger disks. Unraid is not RAID for good reasons. You trade speed for these other benefits. Also, as seen in that video, faster storage is available in cache pool. And recent betas support multiple fast pools.

Unraid does not run from a USB drive. The USB drive contains the archive of the OS. The archive is unpacked fresh at each boot into RAM, and the OS runs completely in RAM. Think of it as firmware except easy to upgrade with no risk of bricking. In addition to the OS archives, the USB drive stores configuration settings so they can be reapplied at boot, but the USB drive isn't really used much and doesn't require speed or much capacity. There is no other way to install Unraid. The GUID of the USB drive is required for licensing.

I just sort of skipped through that video without any audio just to find what I suspected at 5:24. All of the storage is in cache pool, which is btrfs raid, not the Unraid parity array. So he isn't doing

Parity and cache are not required. There must be at least one data disk in the array in order to start the system. Since you don't seem to be that interested in the NAS functionality of Unraid, you might put that HDD as disk1 in the array, and the SSD as cache. It doesn't have to be used to cache anything, it is just a way to get Unraid to manage that disk for you. Then you would setup dockers/VMs to use that cache disk. The usual (cache-prefer) shares for that are appdata (docker working storage), domains (vdisks for VMs), system (docker.img for docker executables and libvirt.img for VM setup). Dockers and VMs would also have access to that disk1 HDD.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Might even be a good idea to shutdown until further advice arrives. I have some ideas but would rather wait on @JorgeB

Have you tried after booting in SAFE mode?

should only be used on specific user shares, mostly because appdata has the permissions required by each container. There is a Docker Safe New Permissions which will do everything except appdata. I don't use this application. Presumably you could delete its appdata and really start from scratch but maybe not what you want. Maybe someone else will have an idea.

Almost certainly flash disconnect. Be sure to boot from a USB2 port. And be sure to make a new post with your diagnostics so we will know to visit this thread again for the new information.

The archives of the OS live on the flash drive. Those are unpacked fresh at each boot into RAM, and the OS runs completely in RAM. I always like to think of it as firmware, except easier to upgrade without bricking anything. Also, the specific configuration is stored on flash so it can be reapplied at boot, and changes to the configuration are written to flash, but for the most part, the configuration is also loaded into RAM for use. @jdlancaster13, as you can see from these posts, Unraid isn't exactly "installed" onto some other disk that you boot from later. In fact, how did you expect to boot it up again since you had presumably told BIOS to boot from flash? Did you have a paid license, or were you using trial? Either way I'm not sure if you can get the license back without contacting support, even if you use the same flash drive. The most important thing for avoiding data loss in your situation is DO NOT assign any data disk to any parity slot, or it will be overwritten with parity. If in doubt, don't assign any disk to any parity slot. And, even after you get through all this and have it working again, you must always keep a current backup of the Unraid flash. You can download a zipped backup of flash from Main - Boot Device - Flash - Flash Backup.

Looks good, appdata, domains, system all on cache. Probably a good idea to delete and recreate docker.img anyway. You might even consider reducing it to 20G. That is what I usually recommend and it is usually more than enough if no application is misconfigured so it is writing into the image instead of to mapped storage. I have 17 dockers running and they are using less than half of 20G. After you recreate docker.img, the Previous Apps feature on the Apps page will reinstall your dockers exactly as they were. If you were using any custom docker network (such as with letsencrypt) you should recreate that after recreating docker.img and before reinstalling the containers.

Those settings are good. By themselves those settings won't do anything with existing files though, and even mover might not move everything. It won't move open files, which is the reason for disabling dockers and VMs. And it won't move duplicates, those have to be cleaned up manually. I will probably have split your post and my response into their own your other thread if you want to continue the discussion so this that other thread can concentrate on the OP.

post new diagnostics

USB2 port more often makes a difference, don't know if it would help here.

Might be useful to other users if you would share your solution.

Go to Settings - Docker and disable then delete docker.img. Go to Settings - VM Manager and disable. Go to Shares - User Shares, click on domains share to get to its page, then set it to cache-prefer. Go to Main - Array Operations and click Move. Wait for it to complete then post new diagnostics.

docker.img is corrupt, can't tell if you filled it up or not since it didn't mount, but the 20G you have allocated should be enough unless you have an app writing into it instead of mapped storage. I see your system share has some files on the array instead of all on cache so in addition to recreating docker.img it would be good if we could make sure it and the rest of system share is on cache. Do you actually have any VMs?

Each user share has a setting for Minimum Free. I am assuming you are writing to a cache-yes user share and not directly to the cache drive.

In my opinion, your cache is too small for much actual caching, since you will want to keep appdata, domains, system shares permanently on cache so your dockers/VMs won't have performance impacted by parity, and so they will not keep disks spinning.