trurl

In the general case of writing new files to a share, Unraid doesn't know in advance how large a file will become, so it chooses a drive for it in advance, based on Split Level, Minimum Free, and Allocation Method.

Another thing you could do to prevent it putting a file on the disk where split level says it should go, is to set Minimum Free for the share to a value larger than the file. Then it would just give you an error since the disk selected doesn't have Minimum Free. All of this works as logically as possible. If you don't want it to use Split Level to decide where to put a file, then don't set the share to use Split Level.

I don't think you have understood this, since it seems to be what you are railing against. If Allocation Method had precedence over Split Level, it would always use Allocation Method to decide where to put a file, and so Split Level would be meaningless. How could it be otherwise? If Allocation Method had precedence, it would take a look at Allocation Method first, and since it gives a clear indication of where to put the file, there is no need to consult Split Level. Since Split Level has precedence, it takes a look at Split Level first, and since it give a clear indication of where to put the file, there is no need to consult Allocation Method.

One thing you could do when using cache and mover is to Exclude from the share any disk you don't want it to move to.

The fact that Split Level has precedence over Allocation Method is exactly what makes it have meaning. Don't understand this part. Isn't that what you wanted, for cache to move them to the Most Free drive, which is the empty drive? In any case, mover is still going to respect Split Level, and if Split level says files belong together on another drive, it will override Allocation.

Since it was 2 weeks later, we were all probably working on other threads we had been helping on more recently, and hadn't had a chance to look at your new posts on this older thread. In particular, I didn't have much time for the forum yesterday. RAID controllers are not recommended for many reasons, including these exact problems you encountered when you changed controllers. Since you had to New Config, you can't rebuild anything except parity. Did you assign the original disk4? Attach Diagnostics to your NEXT post in this thread.

As mentioned, Split Level has precedence over Allocation. And if it didn't, Split Level would be meaningless. Just move from disk to disk, that gives you complete control over which disk a file is moved to.

Ideally, the docker/VM related shares (appdata, domains, system) would have all their files on fast pool such as cache, and configured to stay there, with no files on the array, so Dockers/VMs will perform better, and so array disks can spin down since these files are always open. Nothing can move open files, so you will have to disable Docker and VM Manager in Settings. And Mover won't replace files, so if anything exists in both places, you will have to decide which to keep. Dynamix File Manager plugin can help you work with folders and files directly on the server.

That is the correct documentation to rebuild onto the same disk. The alternative is to New Config and rebuild parity instead, but that will lose anything written to the emulated disk and doesn't save any time. Something has to be rebuilt to get the array back in sync. Another alternative if you insist on USB is to not have any parity disk. That way there is nothing to get out-of-sync when a drive disconnects, so nothing needs to be rebuilt. Of course, nothing can be rebuilt either. USB enclosures that support UASP might avoid some of the problems associated with USB such as no SMART reports, inconsistent or not unique identifiers, incorrect disk sizes. But I'm not sure it will prevent disconnects.

Probably bad memory was the only problem, and the changes you made didn't really do anything except recreate docker image, which got rid of the corruption caused by bad memory. Probably just recreate https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file and reinstall https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications would have fixed it also.

I've never bothered with split level. Highwater allocation will usually keep things together when they are written together. On the rare occasion where allocation changes disks, the only penalty would be a slight delay when another disk has to spinup.

Just in case you have some misconceptions, Parity doesn't have to be any larger than the largest single data disk in your array. Parity is not a backup and contains none of your data. It just provides a parity bit that allows a missing disk to be calculated from all the other disks. https://docs.unraid.net/unraid-os/manual/what-is-unraid/#parity-protected-array

Dynamix File Manager will let you work directly with the disks so you don't have to rely on user share settings.

Not clear what specifically you used, since that is just a link to a Reddit thread. Do you have a link to the actual software? Could be helpful to others.

Attach Diagnostics to your NEXT post in this thread.

Can you access public shares?

Unrelated, your appdata has files on the array.

Has the parity check completed? How many sync errors?

My bad, haven't gotten used to looking at df results for ZFS. Should be OK to rebuild on top of the same disk.

Your downloads share has Minimum Free set to 390500000 KB, which is 390.5 GB. This is more than the free space on any of the included disks.

Just some forum advice. There was a reason I said NEXT post. If you edit a previous post, there is nothing to indicate there is anything new in the thread, and anybody who had already read the thread, such as me, would not have seen any reason to visit it again. But since you also made a new post in addition to editing the first post, the thread was shown as having Unread content.

Attach Diagnostics to your NEXT post in this thread.

Do you have lost+found share now? Repair puts anything it can't figure out in lost+found. Post new diagnostics.