itimpi

The diagnostics posted allowed me to track down a bug in my code. The version of this plugin I have just uploaded should now fix resume not working correctly after drives paused due to overheating and then not starting when they cool sufficiently. If any other anomalies are spotted please report them so I can get them fixed.

There are various settings on a share that control file placement. They are Allocation method, Split Level and Minimum Free Space. You need to read up on these to see what they do. The default values would have Allocation Method set to ‘High Water’ which would send files to the largest disk until it is half full which sounds like the position you are in.

Ok, hopefully that should give me enough information to recreate what is happening so that I can determine why the resume is not working. Thanks for the feedback.

It sounds as though all the current files are on disk1, but that is not inherent. How files get distributed depends on the settings you put on a share. You might want to try turning on the GUI help to see joe the settings interact.

This suggests an error somewhere as the size of the difference should not matter (as long as it gets to the lower temperature). It would be useful if you can get me some diagnostic information covering the two cases. To get this turn on the “testing” level of debugging in the plugin settings and then see if you can repeat the scenarios. After doing that a copy of your syslog (or the system diagnostics zip file as that includes the syslog) should allow me to see what is happening. You will then want to disable this level of debug to avoid filling up your syslog with diagnostic messages).

Yes, this is quite frequently done. there have been some anomalies in the reported used/free space in the GUI when there are an odd number of drives in a cache pool, but they function correctly. I think this reporting anomaly will be fixed for the 6.9.0 release.

Not sure what you mean by this? USB3 works fine as long as the the motherboard BIOS handles it properly. It is just that USB2 is recommended for the boot device as it has proved both more reliable, the devices tend to last longer (thought to be because they run cooler) and Unraid gets no speed advantage from a USB3 boot device as it runs from RAM after the initial boot.

Just to clarify, any UD devices attached at the point of starting the array count. If they are removable devices and you only plug them in after starting the array then they do not count. in practise most users like to have a license that also allows for their removable devices to be left plugged in so they do not have to remember to remove them before starting the array.

You are correct that at its heart Unraid is a basic (Slackware) Linux system using Samba to provide NAS facilities and historically that was how it was used. However the current version of Unraid is also a good application server as it includes KVM/QEMU for running VM’s, and Docker for running apps in Docker containers.

The check/repair does not remove the red ‘x’ as that requires a rebuild, so the disk is still being emulated. What is important is whether the ‘emulated’ drive now mounts OK as when you go through the rebuild process whatever shows up as being on the emulated drive is what ends up on the rebuilt drive.

Click on the Shares tab and if you have User Shares enabled then the array Disk Shares are listed after the User Shares. The Cache and Flash drives have similar functionality but is accessed by clicking on the drive on the Main tab.

Disk shares can have their security set just like User Shares. What you cannot do is then separately control access to the files/folders on the share which could be a security issue.

Do NOT attempt to format the drive or you will lose its contents. Looking at the SMART information in the diagnostics it looks as though the drive is probably fine. the correct way to handle an unmountable drive is covered here in the online documentation. If you are not sure of any step then feel free to come back and ask questions. Data loss is normally only caused by the user taking inappropriate recovery steps. do you have backups of your data just in case something goes wrong?

The message being output by the parity check tuning plugin does not look quite right. Is there any chance you can go into it’s settings and set the Debug logging to ‘testing’ level, reproduce the symptoms, and then post a copy of the syslog (or diagnostics which includes the syslog) so I can get more detail on exactly what is happening? After doing that turn the level down again. My system does not suffer from drives getting too hot so I have trouble testing all real-world scenarios relating to the temperature checks. On the face of it you may have the temperature settings too low but I am not sure. You can also disable the option to pause/resume based on temperature.

Yes - CA Auto Update stops containers while it is running. There are reported instances of it then not always restarting them on completion.

I did not think that docker containers were automatically stopped during a parity check - have you checked this is happening? Docker containers are typically run off the flash drive so are largely unaffected by a parity check. Any array operation is allowed to proceed when a parity check is running as long as one is happy to accept the performance hit.

You can get that symptom if there is a problem reading one of the system files off the flash drive. Therefore another possibility is to download the Zip file for the release and extract all the bz* type files overwriting those in the root of the flash drive.

Turbo write is not applicable if you do not have a parity drive on the array.

All three of these are already covered in the online documentation.

You should post your system's diagnostics zip file (obtained via Tools->Diagnowtics) so we can get a better idea if the state of your system. Some questions: Do you have any drives showing as unmountable in the Main tab? Didi you at any time while trying to recover the drive use the format option (hopefully not). Do you still have the original drive intact as it was at the point you removed it from the array?

Do you have the Minimum Free Space setting for the share set to a value that is larger than the largest file you are attempting to copy?

It DOES count if it is plugged in at the point where the array is started up at any time after booting Unraid. It does NOT count if it is plugged in while the array is already stated (i.e. it is a removable device that you remove while booting).

You only have the Nvidia drivers if you install via the Nvidia plugin - they are not part of standard Unraid.

This suggests that the USB drive did not present the drive to the system in the same way it is now being presented via SATA, and as a result Unraid is not recognising the pre-clear signature. This not that unusual - many USB enclosures do this. If that is what is happening then you will have to let Unraid proceed with the Clear. At least a Clear is much faster than a typical pre-clear cycle. Another common mistake is to format the drive after doing the pre-clear not realising this wipes the pre-clear signature.

If you format an ‘unmountable’ drive then you are effectively discarding its contents. If you want to try and attempt to keep its contents then you need to follow the process for a file system Check/Repair.