trurl

If you want help start your own thread and post your diagnostics.

You have set your m----a share to cache-prefer. Prefer means keep them on cache and if any are on the array move them to cache. Set it to cache-yes so they will be moved to the array. Is that screenshot current? You have filled your log space so nothing has been logged since Feb 29 06:35:01. At that time it looks like you were having connection problems on multiple disks while trying to build parity, and those problems are what has filled your log. Skimming the SMART reports, your array disks seem to be OK. Do any of them have SMART warnings on the Dashboard? Do you have a backup of your Flash drive? Do you have backups of anything important and irreplaceable? Shutdown, check all connections, SATA and power, both ends, including power splitters. Then reboot and post new Diagnostics.

Whether you have one cache disk, or a cache pool of multiple disks, cache is treated as a single volume available to all user shares. In fact, cache is part of the user shares just like the disks in the parity array. Any top level folder on cache or parity array is a user share. One of the settings for each user share is its Use cache setting. It tells Unraid how the user share will use cache, and whether it will move files from cache to array or array to cache. See here for more details on how this setting works: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#comment-537383 You mention dockers and VMs. There are default user shares the system sets up to help manage these, and these are set to stay on cache for better performance. You would not normally store anything in these shares yourself. Each user share has settings that control how it may be accessed over the network. You can even not share some of them, such as those "system" shares.

Do you know what filesystem should be on the disks?

Have you done memtest? Bad RAM has caused this in the past, including for me.

From the point of view of the workstation, you could think of the whole server as one big "thing" and the user shares on the server as folders within that, so I don't see any advantage to having everything in one big share and plenty of advantages to having multiple shares. If you are used to mapping network shares to drive letters in Windows, then each share would have to be a separate mapping. But I don't see any good reason to map shares these days since applications can browse the network.

You could do this, but this means you only have a single user share that all works the same way with the disks and with network access. Most people have multiple user shares so they can have different settings for different purposes. I will ignore the part about RAID0 since I think all you really mean by that is spanning disks, which has mostly been answered. Maybe this will answer more of that. Each User Share can use any available space on any disks that it includes. The entire parity array has parity protection, but this has nothing to do with files. Parity is just a bunch of bits and the parity calculation treats all disks as a bunch of bits. Parity doesn't contain any of your data. Parity PLUS ALL remaining disks allows the bits of a missing disk to be calculated. This is what parity always means wherever it is used. Parity is just an extra bit that allows a missing bit to be calculated from all the remaining bits.

Why did you start a new thread for this? I have merged your threads.

Not sure where you got this idea. Ultimately, you must have zero parity errors. Unless you have some reason to suspect another reason for the parity errors, you must correct them. One likely cause of a small number of parity errors is unclean shutdowns. You must shut down from the webUI or Unraid may not be able to finish parity updates. The number of parity errors you had is not exactly small, but it is small enough to assume you had built parity at some point and didn't do anything that would have invalidated it directly. Why have you allocated 100G to docker image? It is unlikely you would ever need even 20G and if your docker image is growing you have something configured wrong. I see it is already using 20G with only 3 dockers running so it is almost certain that you have one or more of your dockers writing into the docker image instead of to mapped storage. Your system share has files on the array instead of all on cache where they belong. Do you have any VMs? You should start by disabling dockers in Settings - Docker, and disabling VMs in Settings - VM Manager. Leave them disabled until we agree you have resolved your other problems. As @johnnie.black said, your CPU is overheating. You should fix that immediately.

You should post new diagnostics with the array started in normal mode. Have you done memtest? Setup Syslog Server so you can keep syslog after a crash and reboot:

Disable the Docker and VM services in Settings - Docker and Settings - VM Manager. Disabling individual dockers or VMs isn't enough because the services will expect docker and libvirt images to be present. And if you disable the services there is no need to disable individual Dockers or VMs.

Run again without -n

Each disk is an independent filesystem, so each file exists completely on a single disk. But, Unraid allows folders to span disks. This is known as User Shares. Each User Share has settings which control how it uses the disks. This is the User Share setting called Allocation Method. There are 3 choices, High-water (default), Most Free, and Fill Up. High-water is a compromise for distributing files without constantly switching between disks. Each User Share has settings which specify which disks to include, or which disks to exclude. Include means ONLY, Exclude means EXCEPT. You shouldn't set both include and exclude. Unraid has a cache disk, but it isn't a read cache exactly. Its original purpose was for faster writes without parity, then moving those to the parity array at a later scheduled time. Since then, cache functionality has grown to allow multiple disks in a redundant cache pool. People often use SSDs in the cache pool. Each User Share has settings that control whether and how it uses cache. In addition to temporarily caching writes, some User Shares will usually be set to keep files permanently on cache for improved performance of docker and VMs, for example.

https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

If you only use user shares and don't have any settings that use specific array disks then it shouldn't matter. If you are using hardware passthru for any of your VMs then likely that would change with new hardware. Don't enable docker or VM until you have all the files in place.

You can rest assured that parity calculations are only limited by disk speeds. Even dual parity unless you have a very old CPU.

I don't see anything obviously wrong with that. Of course, if you write (copy/move) anything into any folders within Krusader that aren't mapped to host paths then that would be writing into the docker image.

You could do that. You would have to New Config with the licensed flash drive to get the new disks assigned. Or you could just use the Unassigned Devices plugin to mount each disk outside the array on the new system and copy its data that way, no other server involved.

I guess you could use the original system to rebuild each disk, one at a time, to 2.5" disks, then move them all to the new system. You would end up with all of the 2.5" disks in the original system, no putting the 3.5" disks back as you were suggesting. But rebuilding each disk involves reading all the other disks to calculate the data for the rebuilt disk, so in the end just copying the data to the new system is going to be less wear and tear on the disks than any sort of rebuilding scenario.

I think you are overthinking this. What do you plan to do with the original system?

Your shares are simply the top level folders on all disks. Any Settings you have made for each share is in config/shares on Flash. All of your other Settings are on Flash also

If you want to get your data from 3.5" to 2.5" that seems simpler than the questions you ask, so that is why I am having trouble understanding. I would say just make a new array and copy the data to it, either over the network from the old system, or using Unassigned Devices to mount each disk outside the array.

Parity contains no data so copying it doesn't make sense, at least for your scenario. I'm not entirely clear on what your scenario is though. Are you wanting to get your data on other disks? What specifically are you hoping to preserve from your current setup?

That path would make sense if he actually had a mounted Unassigned Device at /mnt/disks/virtualization. Of course, it should also be configured read/write slave if used for this purpose. And even if it is in RAM that is not that same as filling docker image.

So what did you think? It might be worth giving you a better understanding. Misunderstandings can lead to costly mistakes.