itimpi

I do not see anything obvious in the diagnostics although it does look like there is some application reading (and possibly writing) from disk2 which might explain the performance issue. If you can identify which application it is then it will be worth stopping it to see if parity sync performance improves

Yes.

I suspect you have the scheduling settings for it wrong? Post a screenshot from Settings->Scheduler so we can see what you have set. Not directly relevant, but the Parity Check Tuning plugin gives you more fine grained control over parity checks (and other long running array operations).

That might not be enough! You first need to check that you do not have a folder called ‘cache’ on any of your array drives or pools as Unraid automatically creates a share with the same name as any folder at the top level of an array drive or pool. You also need to check you do not have any docker container with drive mapping referencing such a folder or it will keep re-appearing when you start the container.

Click on the word diagnostics which is a link to the instructions. It is standard in this forum to underline links.

You can edit the title of the first post to add (solved) to it.

According to the diagnostics the disk was disabled (has a red ‘x’ icon?) because a write to it failed. To clear the disabled state the normal process is to rebuild the disk. However before doing that run a check filesystem on disk3 and post the diagnostics after doing that and restarting the array in Normal mode. We need to decide if a rebuild is the best action to take at this point. It also looks like you may have one or more docker containers continually crashing and restarting. Look at the uptime for your containers on the Docket tab to identify the culprit(s).

According to the diagnostics you have several shares (including ‘media’) which are set to be array only. With those settings then if any files for those shares end up on the cache for any reason they will stay there as mover ignores any shares with those settings. You probably want to change them so they have primary storage=cache, secondary storage=array; and mover direction cache->array. Mover will then operate on those shares and transfer any files it finds from cache to array.

It is a read check that is checking parity, not a check filesystem that checks the filesystem on the drive.

If you are using power splitters what type are they? A SATA->SATA connector should never be split more than 2 ways or you are likely to encounter power-related issues. A Molex->SATA can typically split up to 4 ways without the same sort of issues.

No point in doing the extended test if the short test fails. If the short test fails then the drive needs replacing ASAP, whereas passing the short test is not definitive and then you need the extended test to get a more definitive answer.

It would be further down the page near to the button for starting the array.

A ‘trick’ that may be useful when using the Manual Split Level is that if you create the same directories on more than one drive then the Allocation method kicks in when selecting one of those drives. This allows you to set up a subfolder that spans multiple specified drives.

When you set parity2 to not assigned did you not have a checkbox that needed ticking to allow you start the array without parity2?

Order slightly wrong. Add it as an additional data disk,; let Unraid ‘clear’ it; and when clear completes you can format it. Formatting it before adding it is pointless as Unraid will still ‘clear’ it. You can copy the emulated drive contents onto the newly installed data disk once it has been formatted as an alternative to copying it to a drive external to the array.