itimpi

Did you have a Minimum Free Space value set for the cache? This is required to indicate to unRaid the threshold at which it should stop trying to use the cache and write any new files directly to the array. It is recommended that this is set to be larger than the largest file you expect to write. Once unRaid has selected a drive for a new file it will give an error if the file does not subsequently fit.

Have you tried clicking on the drive on the Main tab? You should be able to set the values you want there as long as you are on the latest UnRaid release.

These are two separate independent states (although they can be related) and have different recovery actions. A disk is disabled because a write to it has failed and when this happens unRaid will stop writing to it and start ‘emulating’ it using the combination of the other drives plus parity. Does unRaid say it is emulating this drive? If so then this section of the online documentation (available via the ‘Manual’ link at the bottom of the unRaid GUI) is relevant. an unmountable disk instead means that there is some level of file system corruption detected and handling this is covered here in the online documentation. Note that if the disk is being emulated then carrying out a file system repair will be operating on the emulated disk - not the physical one. This can be important as it leaves the physical disk untouched at this point which leaves other options for recovery available if the repair fails for some reason. I would recommend that you should try and fix the unmountable state first.

The parity drive has no file system so it has no files on it. It simply works in conjunction with other drives to provide redundancy against a drive failure. You should probably post your system’s diagnostics zip file (obtained via Tools -> Diagnostics) attached to your next post it might allow us to give some informed feedback.

Strange - it looks like some of those messages may be reported in Celsius and others in Fahrenheit? I wonder if that is causing an inconsistency somewhere? What temperature unit do you have set under the unRaid Display settings? Also, can you check which version of the plugin is installed? it might also be useful if you can provide the contents of your config/plugins/dynamix/dynamix.cfg file from the flash drive so I can check the temp unit setting on your system. I would expect the temperatures in the log messages to have C or F appended and that does not appear to be happening. On checking the code the only way I can see this happening I if a temperature unit type is not set in the .cfg file as the plugin does not assume any default (which I can change so it does). EDIT: I have found that you san definitely get some unexpected behaviour if the temperature unit is not set at the unRaid level. I am ready to push out an update for the plugin that applies a default if not set at the unRaid level. I would be grateful to know if you can let me know if going into Settings -> Display Settings and setting Celsius and hitting Apply fixes your problem as that would confirm I am fixing the correct issue.

Although not part of core unRaid you can get this behaviour if you have the Parity Check Tuning plugin installed and you are running an unRaid 6.9.x release.

You could use the Parity Check Tuning plugin to run the check in increments outside prime time thus reducing the impact on users (at the expense of a longer total elapsed time for the check).

Wouldn’t it be easier to simply disable auto start on all your containers and start them manually?

It might be necessary to give more detail on the steps you took to break them into 2 pools. Sounds as if they may still be running as a single pool? attaching your system’s diagnostics zip filen(obtained via Tools > Diagnostics) attached to your next post may allow for more informed feedback.

Worth pointing out that the Linux ‘file’ command can be used to find out what type of content each file has if you are going to put some effort into sorting out the lost+found folder.

Does the plugin only back up the vdisk files for a VM or does it back up the XML (and potentially BIOS) files that are stored in the libvirt image? If not I would think adding this should be easy and it would definitely make restoring a VM much easier.

I have done that several times in the past without issues. The key thing is that if any step does not go as expected be prepared to ask for help (rather than attempt a recovery if you are not sure what is going on) so that the optimum next action can be determined.

Pulling a disk with the array started will be cause a disk to be disabled and thus emulated.

No as parity has no concept of files - it works at the raw sector level. Parity is only affected by problems reading or writing sectors on the drives. you DO, however want to sort this out as you can get strange behaviour. When multiple copies of a files exists unRaid shows in a User Share the first one it finds (searches pools and then drives in order). This can lead to a case where you delete a file and nothing appears to happen (and potentially the file contents change) as the deletion just ‘uncovers’ the next copy found.

That is by no means an exhaustive list. In principle if KVM supports it then it should work OK under the unRaid KVM implementation.

The general advice is to have a screenshot of the Main tab as if the new system identifies drives differently that should be e nough to let your sort out which drive belongs where. Most of the time the screenshot is not needed but it is an easy precaution to take.

You should provide your system’s diagnostics zip file (obtained via Tools -> Diagnostics) attached to your next post so we can get a better idea of what is going on and how you have everything configured.

A much simpler way to go would be to first upgrade the parity to 8TB and as long as that completes without error use the old 4TB parity to replace the 2TB drive giving you 2TB more data space immediately available. You are then positioned to swap out any other data drive for 8TB drives in the future.

This is not an unRaid 6.9.2 feature but is a feature of the Parity Check Tuning plugin (as indicated by the notification). It would give the same behaviour on a 6.8.3 system. Note that the pause threshold is a setting relative to the Warning level set in unRaid so pausing at 47C if you have the temperature warning threshold set to 50C at the unRaid level suggests you have the plugin settings set to pause at 3C below that.

I would suggest you post your system’s diagnostics zip file (obtained via Tools -> Diagnostics) attached to your next post do we can see exactly what is going on.

You might want to see if you can see any files on the ‘emulated’ drive. You can do this while the rebuild is in progress, and whatever you can now see is what you will end up with on the rebuilt drive.

I think it is a combination? If the drive is running warmer in the first place then larger size helps with heat dissipation. Since USB3 drives seem to run hotter than USB2 ones and as USB2 drives get harder to find then the sizes may well start becoming more important in terms of determining lifetime. My experience is that my small form factor USB 3.x drives run noticeably hotter than their larger size brethren. Offsetting this it is quite possible newer chipsets may become more energy efficient which would tend to reduce heat generation.

There have been lots of reports of the USB Creator tool having trouble seeing USB 3.1 drives - I have no idea what is the underlying cause of this behaviour. It is not clear to me whether the 'manual' method was used with the Sandisk drive? I would have expected that to work as historically Sandisk drives DO have unique GUID's although it is always possible they have changed that policy with their latest drives.

It is also worth pointing out that small form factor drives often seem to have a shorter life span than larger form factor ones. It is suspected this is because they tend to run hotter because their small size does not dissipate heat well which is not good for the electronics of something that is running 24x7.

If you had waited we could probably have given you a way to avoid the need to do this if we assumed the physical drive corresponding to the emulated one was actually OK.