trurl

If you precleared the disk, or let Unraid clear it when adding it to an array that already had valid parity, then it would have been filled with zeros. If you just put it into a new array and built parity, then it would still have whatever data was on it until that data was overwritten by other data. Formatting the disk would have overwritten just a small amount of that data, just enough to represent an empty filesystem ready to receive new folders and files. The original data would not be part of that filesystem and so not accessible in the usual way, but all its bits would still be there on the disk until overwritten. Even a clear disk can supposedly have traces of the original data detectable with special techniques though not with any normal capability of the disk hardware. So

If you set Split Level to Manual, then Unraid will put the files on the disk that already contains its folder. Would require you to manage all the folders manually to get them on the disk you want. Why not just put that special folder in its own share?

Seems like you probably already know this, but just in case someone else sees this thread. The usual cause of filling docker image is an application configured to write to a path that isn't mapped. Using a different upper/lower case from the mappings, or using a relative path (doesn't begin with /) are often the culprit.

Parity2 calculation, unlike parity1, is dependent on the order of the disks, simple as that. And, your syslog says it was correcting Q (parity2). Feb 22 16:32:15 Server kernel: mdcmd (43): check Feb 22 16:32:15 Server kernel: md: recovery thread: check P Q ... Feb 22 16:32:15 Server kernel: md: recovery thread: Q corrected, sector=0 Feb 22 16:32:15 Server kernel: md: recovery thread: Q corrected, sector=8 ... Feb 22 16:32:15 Server kernel: md: recovery thread: Q corrected, sector=816 Feb 22 16:32:15 Server kernel: md: recovery thread: Q corrected, sector=824 Feb 22 16:32:15 Server kernel: md: recovery thread: stopped logging So this is completely normal. Run a non-correcting parity check to verify and everything should be fine.

Here is another thread about this. I don't know if it applies in your case or not.

It's unclear from your post if you are planning to use Unraid. Are you?

If you reorder the data disks then parity2 is not valid so it has to be rebuilt.

This is typical of the way 1G degrades to 100M if one of the signals is missing. In addition to suggestions already given, make sure the pins in the port aren't bent. If they aren't all lined up with the pins on the connector you will get this.

Does the same for me and there isn't any "Next" currently so I assume that is normal.

I wouldn't assume there is driver support for that in Unraid.

Did you have cache disk(s)?

Yes. You will still have your user shares, because the user shares are just the top level folders on all disks. But you won't have any of the settings you made for those user shares, so they will all have default settings. You also won't have any of your other settings, so you would have to do them all again. If you had any dockers then you won't have any of their templates, but if you can set them up again exactly as they were then their appdata should be fine since that is on your disks. You should upgrade. Lots of things better now. And we can support you better.

Answered many times in this thread. This plugin IS a version of Unraid, but with the Nvidia drivers added. Just upgrade from the plugin.

Each additional disk is an additional point of failure. To reliably rebuild every bit of a disk, Unraid must reliably read every bit of parity PLUS every bit of ALL remaining disks. Each disk must be reliable. Any old disks which don't add any meaningful capacity aren't worth wasting a port, and are actually an unneeded risk.

If you have the .key file then put it on your new install on your new flash in the config folder and then you can go to Tools - Registration and get a new .key for your new flash and blacklist the old .key.

Do you have a copy of your old .key file? That is required to get your license transferred to a new flash drive using the automated process. Otherwise you will have to contact Limetech and give them whatever information they need to verify you have purchased a license.

Where do you see this?

Run extended SMART test on cache

Well, you should be able to assign your disks just as they were and not lose any data that was on the disks. And if your data is still there, then you will still have your user shares, because the user shares are just the top level folders on all disks. But you won't have any of the settings you made for those user shares, so they will all have default settings. You also won't have any of your other settings, so you would have to do them all again. If you had any dockers then you won't have any of their templates, but if you can set them up again exactly as they were then their appdata should be fine since that is on your disks.

Do you mean you know exactly which disk is parity, which is disk1, ..., which are cache?

Other possible information that might help are diagnostics or syslogs that you might have saved, or screenshots of Main that you might have saved. It might also be possible to deduce which disks must be parity or cache. If one of your disks is larger than any of the others then that would obviously have to be the parity disk. If any of your disks are SSDs then those were (or should have been) cache. Do you know how your cache pool was configured? Single cache disk or multiple? If we can eliminate the cache drives then all other disks could be assigned as data and none as parity so parity wouldn't be able to overwrite any data. Then we could probably tell which disk was parity since it doesn't mount. Please don't do anything without further advice.

If you accidentally assign a data disk to the parity slot its data will be overwritten by parity. That is the most likely result if you do it wrong. Do you mean you don't have a recent backup, or do you mean you NEVER got a backup of flash?

Why not just put it in the array and format it as XFS? You intend for it to be in the array anyway. Just put it there, format it as XFS, and copy whatever you want to it. No need to get Unassigned Devices or anything else involved.

Do you know which specific disk was assigned to each specific slot?

Do you know how your disks were assigned?