trurl

Your most recent posts are here: https://forums.unraid.net/topic/56462-question-about-disk-format So I think you must have been running some V6 version. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

You should go back in to Settings - Docker, delete docker image and set your docker image to only 20G. That should be more than enough. You can add your dockers back just as they were using the Previous Apps feature on the Apps page.

The parity array is just those disks in Main - Array Devices. That doesn't include any disks in Main - Cache Devices (cache pool) or Main - Unassigned Devices. Only disks in the parity array have parity protection. Disks in the cache pool may have some redundancy independent of the parity array, depending on which btrfs raid configuration you have set up.

The usual configuration is to have VMs and dockers living on cache. So if you wiped your cache that explains both the VM and the docker problem.

If it is still unmountable, it is possible that the filesystem can be repaired. Do you know what filesystem the drive should have on it?

You can't do passthrough at all then.

That first screenshot says you have selected Main instead of the Dashboard.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. Even better, post diagnostics taken from each of those conditions.

The thing to be aware of with dual parity, is that the 2 parity disks are not interchangeable. Parity2 is a different algorithm. So, parity2 is not the same as parity. Either parity will provide redundancy for a single failed disk. But since the 2 parities are not merely copies of each other, together they can provide redundancy for 2 failed disks. So, if you add a parity2, and then make your original parity disk a data disk, you will not have a parity disk in your array, you will have a parity2 disk.

And, to continue with Squid's point, even if you do have a drive failure, you should be able to recover from it. That is the whole point of parity, after all. And you should always be sure you have another copy of anything important and irreplaceable. Parity is not a substitute for backups, and if you have a good backup plan, you should be able to worry less about a new disk having "infant mortality".

If you can't flash it to IT mode, then it may be more trouble than it's worth to try to use it, and you would be better of with another card. RAID controllers may not pass the disk serial number as the disk identifier. That is how Unraid identifies which disk belongs where, and if that isn't consistent, it will not remember your disk assignments. RAID controllers also may not pass SMART information to Unraid, which it uses to monitor disk health and alert you if a drive is having problems.

Unraid only requires a clear disk when you are adding it to a new slot in an array that already has valid parity. This is so parity will remain valid. A clear disk is all zeros, and all those zeros have no effect on the parity result. If you don't preclear a disk when adding it to a new slot in an array with valid parity, then Unraid will clear it for you. So, preclear is never necessary. Much older versions of Unraid would take the array offline when clearing a disk, so preclear was created to clear the disk before (pre) adding it to a new slot. People still use preclear to test and "burn-in" a disk. If you want to test a replacement disk then you can use preclear for that, but a clear disk is not required for a replacement disk.

Just to elaborate on what itimpi already said, an empty disk is not a clear disk. A clear disk is all zeros. Removing or adding a clear disk has no effect on parity, since all those zeros produce the same parity result. An "empty" disk is far from all zeros. It actually still has all of the bits it ever had with whatever values were there before. It is just the small amount of filesystem metadata that says that those bits are no longer part of any file. And all those nonzero bits are still part of parity, so removing them requires a parity rebuild.

Note however, that parity swap does actually disable the array during the "parity copy" part of the procedure. Actually, on second thought, forget the parity swap. Just rebuilding parity with whatever drives assigned as you want is the best way to go. And you can do this all at once, removing the 2TB, adding the old parity as data, and adding the new parity and rebuilding it.

If I understand correctly, where you want to end up is with a larger parity drive, and the original parity drive replacing a 2TB drive. Is that correct? If so, then parity swap seems entirely appropriate. You don't really have to have a "failed" drive. If you disconnect, or even just unassign that 2TB drive and start the array, Unraid will disable it and it will effectively be "failed"

Won't hurt

I think your approach will just be more trouble than it's worth. Unraid does not do RAID itself, except for various btrfs raid configurations in the cache pool. Best to not use any RAID controllers, and just use the 8TB drive as parity and the others for data. With that 8TB as parity, you will be able to replace any of your other disks with larger disks later (up to 8TB). Even if you could do 2x4TB RAID0 as parity, it is not certain whether or not that 8TB would be large enough to allow a standard 8TB data drive in the array.

Can your server reach the internet?

Also, why do you have 100G allocated to docker image? That usually means a user has their docker applications misconfigured. 20G will usually be more than enough, and if it grows beyond that you need figure out what you have done wrong. An application will write into the docker image if it is writing to a path that isn't mapped to Unraid storage. This often happens from using the wrong upper/lower case, or from using a relative instead of an absolute path. On the other hand, a container will write into memory if it is mapped to a host path that isn't actual storage. Note that an unmounted Unassigned Device isn't actual storage either.

Does it happen with no dockers or VMs?

Or another of my favorites:

Since this is not about an Unraid release, but instead is about a docker, it obviously doesn't belong as a Stable Release Report. For future reference, if you think you have a bug to report, see here: Also, you can go directly to the correct support thread for any of your dockers by simply clicking on its icon in the Unraid webUI and selecting Support.

Since this is about a docker, it obviously doesn't belong here. Copied to General Support

Changed Priority to Other