trurl

I assumed you were talking about this thread which explains how parity writes impact write speed. Here it is in case you haven't seen it:

They can but they won't be bootable until you make them bootable. https://wiki.unraid.net/UnRAID_6/Getting_Started#Manual_Method_.28Legacy.29

If you have a backup with the nvidia build then using that backup will result in the nvidia build. Or you can just use a normal build with only the config folder from the backup to get going again, then reinstall nvidia the same way you did before.

You didn't say specifically what that same error was. That is the problem with using old threads that seem similar to your problem instead of explaining your problems in detail in your own thread. There are probably hundreds of threads on this forum with flash drive problems. Now there are 3 of you tagged onto this old thread without any real details or replies. Does it boot at all? What happens after booting?

That's the way I took it also. I was just explaining why UD was even brought into the discussion since it would not normally be needed.

Trying to do multiple disks through a single port is going to perform very poorly when multiple disks need to be accessed. And rebuilds, parity checks, access ALL disks simultaneously. Even a simple write to a single disk requires accessing parity and the written disk simultaneously. If you can't give each disk its own SATA port maybe reconsider not having parity at all. Whether or not you have parity you still need backups. You must always have another copy of anything important and irreplaceable.

You can probably use that backup, just delete config/super.dat and it will make you reassign your disks.

Boot from a USB2 port

And the thing to remember about Minimum Free. Unraid has no way to know in advance how large a file will become when it chooses a disk to write. If a disk has more than Minimum, the disk can be chosen, and if the file is too large for the remaining space, it will fill until it errors. The usual recommendation is to set Minimum larger than the largest file you expect to write to the user share. Note that this doesn't mean the space will never be used. If you set Minimum to 50G, the disk still has 60G free, it can be chosen. If you then write a 40G file to it, it will only have 20G after that, so some of that space was used. But the disk won't be chosen again since it no longer has more than Minimum. Also remember that Split Level has precedence. I always user Highwater and let it split anything, since the only consequence of splitting is a slight delay while another disk spins up. Basically same points testdasi and Frank1940 made.

Nothing obvious in syslog. I see disk1 completed extended test without error. Have you tried extended tests on the other disks? Don't understand this part. Do you mean you are repeatedly running parity checks? You mention not having enough ports. Most would argue 2 cache pool is more useful than dual parity when you only have 2 data disks. But since you are still having problems, I am wondering. Anything unusual about how these disks are installed and connected?

This means your flash drive had disconnected. You should use a USB2 port for flash.

USB connections in the array or cache, while allowed, are not reliable enough to keep all disks connected all the time. When a disk disconnects in the parity array, it will be disabled and will have to be rebuilt. This will probably be a frequent and recurring problem. If you want to run without parity then it won't matter so much if something disconnects since there is nothing for it to be out-of-sync with. The eSATA might be a good choice for cache then since it won't get disconnected. The only difference between eSATA and SATA is the connector. You just need a cable with eSATA on one end and SATA on the other.

The only reason I brought Unassigned into the picture is because you had already formatted the emulated disk. I thought the physical disk might still be something we could work with Unassigned, since putting the disk back into the array would have rebuilt it with the empty filesystem.

I encourage that attitude, and I enjoy teaching how this all works. Some people probably get tired of all my explanations. Doesn't matter what is on the disk since it will be completely overwritten during the rebuild. But formatting a disk in the array is where the mistake is. Many people only have a vague idea about what format does. They often think it is just "prepare a disk for use", whatever that might mean. Format doesn't do anything except write an empty filesystem to the disk. That is what format has always meant in every operating system you have ever used. That empty filesystem is just the metadata that represents an empty top level folder ready to receive new folders and files. But note that format is a write operation. Unraid treats it just like any other write operation, by updating parity. How could it be otherwise? Parity needs to be in sync with that empty filesystem you just created. So when you rebuild a formatted disk, the result is a formatted disk. While you don't need an empty disk, there is one (and only one) situation where you need a clear disk. But a clear disk is not an empty disk, a clear disk has all zeros written to it. A clear disk is required when you add a disk to a new data slot in an array that already has valid parity. This is so parity will remain valid since all those zeros have no effect on parity.

Are you trying to use USB drives in the array? Not a good idea. Not a good idea for cache either.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Parity check shouldn't have that effect, unless of course parity check is revealing problems with access to your data. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Did you also disable VM Manager in Settings?

Have you done memtest?

I will probably copy this to General Support after we get more information or if we don't.

See the instructions for reporting bugs here:

If you started rebuilding the disk then you might as well let it complete and accept the formatted empty disk result. Then it will be in sync with parity and your array will be protected again. Then you can go to your backups for the files. First mistake was not asking for advice before doing anything. Even then we probably could have helped if you had waited for further advice.

Did your last parity check have zero errors? Did you make any disk changes since then? Go to Main - Array Operation, click History, and post a screenshot.

https://wiki.unraid.net/UnRAID_6/Getting_Started#Registering_and_Installing_Your_Key

So you formatted the emulated disk, not the physical disk. And that emulated disk is empty. The physical disk may still have your files. Stop the array, unassign the disk, then restart the array with the disk unassigned. Do NOT reassign the disk to the array or it will be rebuilt as the empty drive that is currently being emulated. See if the disk will mount as an Unassigned Device using the Unassigned Devices plugin.