itimpi

The update should not be relevant to your issue but no point in not using the latest version I have looked through the diagnostics that you provided and the strange thing I see is that I can see at 01:48:33 that the plugin's monitor task started but then I do not see it finishing! At this point the plugins monitor task seems to stop running. Since it is that that is meant to detect the mover has finished and it is time to resume the array operation the fact the monitor task is not running explains why the operation was not resumed. However I know of no obvious reason that the monitor task should stop running - the only thing that should change is the frequency depending on whether the plugin thinks it is idling or not. If you get the situation occurring again can you perhaps go into the console level and let me have the results of running cat /etc/cron.d/root so I can check that it still contains the entries for running the monitor task at regular intervals.

You should not (as far as I know be getting this if you are up-to-date with the plugin. I do not see it in my testing but there may be something I have not set correctly to rigger this. If you ARE up-to-date then you can try enabling Settings->PHP Settings and set it to show all errors. You should then see an entry to coincide with the syslog entries that gives the line number in my code where things are going wrong. Letting me know that should make it easy to pinpoint the cause and thus fix it.

Not using the plugin. The easiest way might be to consider writing a User Script that you initiate after the parity check is started that keeps looking to see if the check is still running, and if not issues a shutdown. Technically it would be easy to add a feature like this to the plugin but since it can be hard to accurately predict when a check would finish I am not sure how useful it would be in practice. You might find the system suddenly shutting down unexpectedly while you were using the server. If you can make a good Use Case for this feature I can consider adding it in a future plugin update (with the default being to NOT auto-shutdown).

Not quite sure why you are talking about the 6.12.0 rc7 release if you are 6.12.2? Have I missed something?

I do not think the -p option now works - you need to set the port via Settings -> Management Access if want it to be something other than the default.

There is no built in cluster support

The second one is the worrying one - it implies you have something writing to a location that is RAM.

Had you stopped the array? Not currently in a position to check, but I suspect that is needed.

This will be because Unraid is ‘emulating’ the missing drive using the combination of the other data drives plus parity drive. When you put in a replacement for the drive what is showing on the emulated drive is what will be rebuilt onto the replacement dtive.

The rebuild starts by replicating exactly the existing disk contents, and then when it completes that stage the file system is expanded to fill the whole disk. It is possible that you may have to reboot to get the file system expansion to take place although in theory the reboot should not be necessary.

I believe tht the issue is often memory fragmentation rather than total memory, and I think the swap file option helps with this.

Anything involving parity only applies to array drives - pools are not affected.

If you started the thread then you can edit the title on the first post.

I would say off-hand that drive looks a big suspect with the large number of Pending Sectors ad on a new drive I would expect that value to be 0. There is a faint chance that if you run a pre-clear on it the value will go back to 0 but I would not be very hopeful.

This sounds more like there may be some sort of restriction applied to the browser in your work environment.

* did you do the check of trying to stop the array to check: How long that takes if the stop is successful If the stop is unsuccessful, what is it that is stopping the array from stopping.

I think it is very unlikely as the view is meant to be the same regardless of the browser you are using.

Had you had any suspected unclean shutdowns or anything else that might indicate you should expect some errors? I notice that disk3 and disk6 indicate in their SMART information that they may have had connection issues at some point as they have non-zero values for the UDMA CRC attributes. This may be a red herring as since this attribute never resets to zero it could be quite an old issue. You might want to consider, however, running a check filesystem on the array drives to make sure none of them seem to have any current file system level corruption. I also notice that you seem to have the regularly scheduled scan set to be correcting. It is normally recommended that this scan is set to be none-correcting so that you do not have a drive that is playing up inadvertently corrupting parity. You normally only want manually initiated scans to be set as correcting as that gives you a chance to look into why a scheduled scan is reporting errors before any changes are made to parity and only issuing correcting checks when you are confident there are no obvious hardware issues.

I have not had a chance to review his change as I have been away from home this last weekend,, but it should be irrelevant to the issue you seem to have.

@DontWorryScro Something strange going on as it appears that the plugin thinks the check was manually paused rather than being paused by the plugin which was why it was not resuming. I will have to check to see if I can work out a scenario where that can happen. Also worth mentioning that you do not seem to be on the very latest version of the plugin, but the last update was largely cosmetic so should not be relevant. if I cannot work out why your issue arose are you prepared to try to repeat your issue with the Testing mode logging active in the plugin? That can generate a LOT of additional logging but it does give detailed information on the internal workings of the plugin that is of value to me.

Since you have 18TB parity drive you can rebuild to a replacement 18TB. It will initially rebuild the contents of the (emulated) 8TB drive and then on completion expand the file system to fill the whole drive.

Those types of errors tend to indicate connection issues. It is worth checking that all cables (power and SATA) are well seated as they can work loose due to vibration and/or thermal effects.

The easiest thing is to use the Mirror to Flash option and then the file is in the logs folder on the flash drive.

You should just try stopping the array and see how long it takes, and then increase the timeout to something like 30 seconds more than that. If it will not stop the array you can investigate what is keeping it from stopping.

This section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page discusses this issue.