trurl

This is more than I wanted you to do. Post new diagnostics.

Or don't cache user shares as much. Caching user shares are not required and not done by default. Consider whether and what you want to cache. Most of my user share writes are scheduled backups, queued downloads, and other unattended processes so I don't care if they take slightly longer. And the other writes I do aren't large so I just don't bother with caching them. You definitely don't want to cache the initial data load, cache just gets in the way for that since data can't be moved from cache as quickly as it can be written. Mover is intended for idle time.

"Newbie" Did you read the instructions at the link? You must read the whole thing and you have to follow the instructions exactly. Where in the step by step are you specifically having an issue? This doesn't appear until step 13.

Post diagnostics

not the syslog

You were going about it wrong then. Parity swap would have been the way to go, you should have asked before doing anything. Parity2 is not interchangeable with parity, and no data drive can be larger than any parity drive. I think you can stop parity2 sync, unassign parity2, then you will be at a position to do the parity swap with parity. Study the link given earlier and let us know if you have questions.

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

Was it your intention to have dual parity when you were finished?

I do have some question about this statement though. What do you mean when you say "RETRY to correct the filesystem"? Did you try XFS repair on any of the disks? And you have it exactly backwards, rebuilding from parity (with the invalidslot command in this case), then correcting filesystem if necessary will be the way to go. Rebuilding after correcting filesystem would just rebuild back to before the filesystem was corrected. Another thing I noticed earlier in your comments Parity has no filesystem so XFS repair of parity makes no sense. For future reference, just replacing a smaller disk with a larger disk and rebuilding one at a time was the correct way to go here. The contents of the original disk would have been rebuilt onto the new disk so emptying a disk isn't needed.

The reason I think it was disk2 that you mistakenly assigned as parity is from the syslog here: Feb 15 14:33:54 Dozer kernel: md: import disk0: (sdb) WDC_WD80EMAZ-00M9AA0_VAG2DXEL size: 7814026532

It looks like the correct drive assignments are: Jan 11 20:04:44 Dozer kernel: md: import disk0: (sdd) WDC_WD80EFAX-68KNBN0_VAK5ZK3L size: 7814026532 Jan 11 20:04:44 Dozer kernel: md: import disk1: (sdc) WDC_WD80EFZX-68UW8N0_R6H1KKHY size: 7814026532 Jan 11 20:04:44 Dozer kernel: md: import disk2: (sdb) WDC_WD80EMAZ-00M9AA0_VAG2DXEL size: 7814026532 Jan 11 20:04:44 Dozer kernel: md: import disk3: (sde) WDC_WD10EACS-00D6B0_WD-WCAU40301372 size: 976762552 Jan 11 20:04:44 Dozer kernel: md: import disk4: (sdf) WDC_WD10EACS-00C7B0_WD-WCASJ1280244 size: 976761492 Let us know when you are ready to proceed. Don't do anything without us.

Your idea about XFS repair is probably not going to help. Rebuilding the disk from the correct parity and other disks assigned as they were the last time parity was correct is going to be the best hope. It might be useful to use one of those new disks for the rebuild though and keep the original disk2 in reserve in case anything can be recovered from it. Give us a while to study this new information and see what we can come up with.

If your ultimate goal was to replace some smaller drives with larger drives you were going about it all wrong. Emptying disks and new config were completely unnecessary.

Sounds like parity would need the 2 empty drives also. And I assume it would be best if we could figure out which disk was parity without having to mount them all as data. @isaw Do you have any screenshots, diagnostics, or syslogs from before? Do you have backups of anything important and irreplaceable?

See my reply and don't do anything except get us the diagnostics. And forget about drive letters. Drive letters are not guaranteed to be consistent from one boot to another, especially if you add, remove, or change disks connections. Unraid identifies drive assignments using the disk serial numbers. The serial numbers are the only thing you should pay attention to except when advised otherwise.

When you don't know which drive is parity you should assign no parity drives and assign all as data. The parity drive will be unmountable since it has no filesystem. In your case you will have another unmountable drive, the one you wrongly assigned as parity. You will have to do invalidslot to have any chance of rebuilding the data disk. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. Then don't do anything else and wait for further advice. Since it is late for some of us you may be waiting a few hours to get that further advice.

You should post Diagnostics, not syslog

The thread you posted in is pretty old. Might be more useful to you to start a new thread with a more detailed description of your issue and your Diagnostics.

See Windows Issues "sticky" pinned near the top of this same subforum.

I may move this discussion to General Support. See Report Guidelines here:

Your question is unclear to me. Take a look at the Docker FAQ pinned near the top of this same subforum and see if that helps.

Unassigned Devices plugin

See here for an explanation of how the 2 different methods of parity update work. As you can see there is some overhead and either way it will not perform like single disk writes.

I had mentioned that earlier. When you anonymize your diagnostics, we can't tell the actual name of any shares, we only get the first and last letter, with any letters in between replaced with - . Take a look at those diagnostics you uploaded, look in the shares folder. Might be interesting to you to look at other things in there as well, it is all text. Many of the files are just settings from the webUI. And because of DOS/Windows naming conventions, the files in the diagnostics are not case-sensitive, but on the actual server the share names and practically everything else is. Often, people will accidentally create shares with the same names except for upper/lower case, by incorrectly specifying a path in docker mappings or somewhere. This actually results in different shares, but they look the same in the diagnostics, except they get (1) appended since you can't have 2 files with the same path. This can also confuse the user share settings, since often the settings file will be for a share that doesn't even exist, and the similarly named share will have no settings file, so gets default settings. In your case, I could see that both shares existed because diagnostics said they both had files.