itimpi

The 6.10.0 rc versions have been available for many months now via the ‘next’ branch. No idea how long until it reaches ‘stable’ status but I suspect that is getting close.

You may find this section of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI is relevant.

Not much point in continuing the rebuild with errors affecting multiple drives it is likely to be something they share such as the disk controller, or power supply.

Boards can work loose in slots so it is always worth trying a reseat.

I also notice a lot of items appear to be loaded via Nerdpack and it is possible one of them is not compatible with this release. It might be worth running in Safe Mode for a while as this would suppress any plugins runningand if that works it will give you a starting point for further troubleshooting.

A normal reboot will be considered unclean if the array did not get stopped before the shutdown timers activated. it might be worth reading this section of the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

I do not know myself - hopefully someone else knows the answer and will chime in

You should be good to go. Simplay stop the array; assign it as a parity drive; and restart the array to start building parity on the drive. Strictly speaking the Preclear was unnecessary as building parity writes to every sector on the drive anyway. However it does act as a confidence check on the drive’s health before attempting to use it as a parity drive.

Your syslog seems to be full of messages of the form: Mar 31 21:50:03 Hades kernel: pcieport 0000:00:1d.0: AER: Corrected error received: 0000:0b:00.0 Mar 31 21:50:03 Hades kernel: nvme 0000:0b:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Mar 31 21:50:03 Hades kernel: nvme 0000:0b:00.0: device [c0a9:540a] error status/mask=00000001/00006000 Mar 31 21:50:03 Hades kernel: nvme 0000:0b:00.0: [ 0] RxErr Not sure of the cause and if they explain your issue, but it is possible they do: BTW: your Parity Check Tuning plugin is not the latest version. You want the 2022-03-31 version.

Yes, but what access rights on that mapping.

What access have you set for that folder in the containers volume mapping?

I believe so.

Not sure what is going on for you? I get a pop-up allowing me to change the mount point (and thus share name)

At least it means that at some point in the past someone else thought this was a good idea

You are only meant to get told again if it changes The value is saved to the flash drive when you acknowledge it so maybe there is some issue getting the saved value off the flash drive?

If you had never explicitly set anything up then you would have the default settings. Once you set up any setting then the ones displayed get saved and used going forward. I pushed out an update earlier today to give better defaults for those who never change any of the plugins settings. Did you read the built in help regarding how the heat pausing values work? If so and it was not clear maybe you can mention what you found confusing to it can be improved. It is possible to revert to default values by either deleting the .cfg file in the plugins folder on the flash drive, or by removing and reinstalling the plugin. I will think about whether adding a Defaults button adds value - it would be trivial to implement but may be unnecessary now I have mad the initial defaults more like what a typical user would want.

Click on the blue text opposite the '1' in your screenshot (the 2nd line)

Did you try changing the increment frequency to be Daily rather than Custom? I checked and the Custom value is what you currently end up with if you never have gone into the plugin settings to make a change. One of the not-visible internal changes was to how default values are set if the user never explicitly sets values. I can change the Frequency to default back to Daily on such a case. Since you mentioned only having this problem on your 6.9.2 system I will try to see if I can get different behaviour on a 6.9.2 system compared to a 6,10.0-rc* variant.

Always maintains parity was why I suggested doing the Parity Swap procedure twice as each time around you are still protected against another drive failing by the parity you are NOT doing this process on. The first time round you get a 16TB drive as one of the parity drives and the 14TB drive that was parity replaces the selected data drive. During that process you still have the data drive being replaced intact in case anything goes wrong. You then repeat for the Parity Swap procedure to replace the other parity drive with a 16TB drive and get that 14TB drive to replace another data drive.

According to that screenshot you have set custom pause/resume using crontab type entries to pause/resume every 5 minutes! That is the sort of thing I do during testing (one of the reasons I added the crontab format option) but not something I would expect to see in normal use

Those error messages strongly suggest there is a physical problem with that drive. You are likely to get better informed feedback if you post your system’s diagnostics zip file.

The current implementation of Unraid assumes that files only exist in one place (array or a pool) so if I understand what I think you are asking for this would be a major change.

Click on the name and change it to the name you want.

You could use the Parity Swap procedure covered in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI. in theory you could do 2 both parity drives at once but you may prefer to do them one at a time in case you get an error on another drive during the procedure.

Can you please confirm whether the update I have posted has fixed the handling of temperatures on your system by the parity check tuning plugin. I find testing this feature particularly difficult as I have to simulate overheating as my drives do not actually do this. if there is still a problem then raise it in the support thread for the plugin.