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.

What makes you think the emulated disk is not being mounted? Both your screenshot and the earlier diagnostics show it mounted with about 12% of it containing data. The whole point of Unraid’s emulation feature is to allow the system to operate as though a failed/missing disk is actually present.

The parity disk(s) are optional in the array depending on if you want protection against disks failing., but you must have data disk(s).

The ‘little blue box’ is standard. You click on it to initiate File Manager. The NTFS question still applies - it is the file system you have set for the emulated disk1. Parity drives have no file system. Not sure what you did originally but disk1 is still being emulated so needs rebuilding to make it active again.. However since it is in NTFS format ideally you would copy it s contents elsewhere before rebuilding disk1 and copy the data back afterwards once it is formatted to a Linux style file system (probably want Xfs). Not sure why you have 2 parity drives protecting a single data drive. You may be better off using one of them as an additional data drive instead.

The system gets very confused if you have folders on the drives with the same name but different capitalization. Make sue that any paths in docker volume mapping are as you want them to end up, It would be easiest to Unraid's built-in File Manager to move files to the correct location. I would recommend that any docker containers that might use these paths are stopped while doing this. After that check the /boot/config/shares folder and check if there is a .cfg file with the capitalization that corresponds to the actual share folders on the drives. That system uses FAT32 so you cannot simply rename one to the correct capitalisation in a single step. If there is one with the wrong capitalization then remove it and return to the shares tab and make sure the settings for that share are as you want them. When you hit 'Apply' a new .cfg file will be created with the correct capitalization.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information. If anyone spots anything and comes to a conclusion you can then ask where they spotted the information that lead them to a suggestion if you want to think about doing this for yourself in the future.

The Licencing scheme allows for free upgrades within the given point release even if not eligible for upgrades to a later point release. Since you are 6.12.10 you should be able to upgrade for free to 6.12.15 which is the last release within the 6.12 versions of Unraid.

In terms of checking config files (*.cfg) it is worth mentioning that they should all be human readable text files so opening them in a text editor tends to make it obvious when corruption has occurred.

Normally I would suspect something like a too restrictive Split Level causing this type of issue or perhaps the include/exclude on the share settings but it does not look like this is the issue looking at the share .cfg files in the diagnostics you supplied. It might be worth checking that you do not have a job explicitly writing to disk4. The most likely candidate is whatever is writing to the B----------s share as this only exists on disk4.

Yes. You can also delete the preclear_reports folder. Not sure what that Android folder is? Maybe it is not needed either.

Looks like a lot of corruption was detected. You only ran the check according to the attached log - you did not appear to have run a correction? Not having one is a good sign. However that check is one to make AFTER running a xfs_repair in ‘fix’ mode.