itimpi

It may be possible to set this up, but even ignoring the limitations imposed by parity I do not see why you think this would improve performance. You would still be only reading/writing to one of the vdisk files at any particular point in time - this type of arrangement does not give any sort of ‘striping’ which is the technique RAID uses to improve performance.

Difficult to help without more information to go on. I would suggest that you post a screenshot of the settings for the problem Docker container so that we can see if anything looks wrong. It might also make sense to post your system’s diagnostics zip file (obtained via Tools->Diagnostics).

Unless you have a reason not to do so, why not leave the option to run it automatically overnight active as well? That way you may get most of the moves happening in what would otherwise be idle time.

That would work It has the added advantage that the system should now boot slightly faster.

You can do that by editing the first post in the thread and adding (SOLVED) to the title.

You may find this section of the online documentation to be of use. As was said earlier the system diagnostics zip file (obtained via Tools -> Diagnostics) is needed to give any sort of informed feedback.

Have you assigned any drives to the array - the screen shot appears to suggest not. The other possibility is that the Unraid USB is offline for some reason.

This just seems to happen to some users with certain combinations of hardware and Linux kernel. It can therefore start happening any time an Unraid update includes a new kernel. As far as I know nobody has ever worked out the exact cause and therefore a fix.

You start getting results with more than 2 drives that will be different to traditional RAID.

No. BTRFS RAID levels are not quite like traditional ones, but with mismatched sizes this can affect the available space. You can use this site to see what is the available space for different combinations of disk size and RAID profiles

If you keep getting the same sectors reported in the syslog as having errors then this is a sign that the drives are reading OK.

You only want to do this if you think the disk is OK. Running a correcting parity check if a disk is giving read errors can cause spurious errors and end up corrupting parity.

That would only be true if it is a correcting check. With a non-correcting check any parity errors are NOT corrected and would continue to be reported until a correcting check is run.

You can transfer the license once per year using the automated transfer process. if for some reason you need to do it again before the year has expired then then you need to contact Limetech by email with an explanation of why. You should also (if possible) provide enough information for them to identify your licence (e.g. purchase email or the GUID of the USB stick that currently has the licence attached to it) and the GUID of the new USB stick you want the licence to be associated with. They then normally do a manual transfer for you and email back with the new key file attached. If transferring to a new USB stick I would suggest that a USB2 one is better as they seem to be far less prone to failure (I suspect because they run cooler) and no noticeable performance advantage is gained from a USB3 one as after initial load at boot time Unraid runs from RAM.

How many drives work, and how are they connected? Some BIOS’s seem to get upset if you have more than 12 drives in the system unless you disable the options for all of them to be treated as potentially bootable.

There is no officially supported way to do this. you might be able to do something using the docker that allows for building your own custom Unraid kernel.

Don’t know about the CPU setting, but there have been lots of posts about XMP on the RAM being an over clock that can cause issues.

You have specifically chosen the option to only access the server in the Peer type. You need to use Remote Access to LAN if you want to access more than the server.

I have actually gone ahead and added this as an extra option in the Parity Check Tuning plugin as this ends up both being a logical place to put this option and also the least work for me. A parity check or other long running array operation is also probably the most likely thing to trigger such a level of overheating. Despite the name of the plugin if you activate this option it will apply regardless of whether any long running array operation is currently in progress.

You can never rely on the stX type names not changing as they are assigned dynamically during the booting process so various timing factors can affect the order they get assigned. Instead you can use one of the names shown under the /dev/by-* type folders if you want an invariant name

UdMA CR`c errors were connection issues that would have caused retries at the time until the transfer either completed OK or a failure was reported. As such there is nothing to re-check. Also the count never gets reset - it can only increase, so as long as it remains stable you are no longer getting such errors.

My first idea was unToasty or unToasted

It would be easy enough to write a plugin that detected if overheating of drives is happening. Whether that should just send a notification or force an automated shutdown is an interesting philosophical point. I guess it could be configurable. I could easily enhance the parity tuning plugin to send a notification on drives overheating even if no parity check is running. Not sure if this would be the right way to handle this - a separate plugin seems a better solution. I might look into putting together such a plugin if sufficient interest is shown as I should already have all the bits required to assemble it. Time to start thinking of a good name for such a plugin

True, but that was the Use Case specified. It does not need to be a scheduled check for the temperature related pause/resume to kick in.

As a workaround you could install the parity check tuning plugin and switch on the option to pause when drives overheat.