itimpi

All my flash drives have also had years of use. I suspect that many people starting out on Unraid go for the newer USB3/USB3.x type flash drives not realizing they provide no real speed advantage when used with unRaid , tend to be far less reliable; and typically cost more than USB2 drives

It could be either of those, or perhaps the RAM. Check you have all the required power connector to the motherboard - sometimes the extra one gets omitted by accident..

The diagnostics you have just posted showed that Perl DID install. Sounds like there is a disconnect somewhere?

I am confused - according to that screenshot the install finished so what makes you think otherwise?

All you need to do is copy across the ‘config’ folder to get all your configuration information onto the second USB stick. having said that if the second USB stick is not on the same Unraid release you may want to copy across everything from the 1st one. Make sure you keep track of which license file goes with which stick (and ideally have them backed up somewhere safe).

The 6.9.0 release (currently at rc2 status) introduces support for multiple pools (instead of just the single cache pool supported in 6.8.3) so that might be a way to utilise the spare drives?

What makes you think most people do not use this feature? Note that probably the most common problem that most people seem to encounter is corruption at the file system level (for a wide variety of reasons) of the drive hosting the vdisks rather than drive failure. As the disk has not failed the corruption will end up mirrored into parity so unRaid cannot help. In such a case Unraid cannot help and it is up to the RAID software running in the VM to realise that a vdisk is now corrupt and needs recovering. That is why most people back up their vdisks at periodic intervals so that they have a point in time they can always revert to if needed when things were known to be good.

I have successfully used UFS Explorer under Windows. It is not, however, free for recovering files of any size although I believe the trial version will show you what files it can find.

In principle the standard Unraid generated entry should be replaced by the plugin one that has more information. All the logic for both generating the notification and updating the history is contained in a single function so that looks like what I need to focus on - obviously managed to break something in the logic in a recent update.

this is much more likely to be a coding in the plugin where it is incorrectly saying it is aborted when it is not! it is only recently that the plug-in has even tried to generate a message at the end of the parity check. The idea is that it will be more correct than the Jnraid generated one. I am trying to stop both notifications coming out but if the plug-in one is misleading it may be better in the short term that they both come out. I would be interested in some feedback in what the parity history is saying for that particular check. I think there is a good chance it will actually be correct.

If it is a VM then the RAID support is running inside the VM not at the Unraid level so it is the responsibility of the VM to handle the exact scenario you asked about. if you mean that a physical disk fails that contains the vdisk files and they are on disks being protected by Unraid (I.e. not on Unassigned Devices) then Unraid will rebuild that disk. In this case Unraid is unaware of the RAID part but it knows what should be on that drive.

The thing is the plugin never "runs" the parity check - it can only pause/resume one that Unraid is running. Maybe there is something wrong about the completion message suggesting it has aborted when in fact it has not? What does the Parity History for those runs say happened?

Earlier you said you wanted to pass the entire nvme drive through, but the path ends in vdisk1.img which suggests you are trying to use a vdisk image file on the nvme Which is it?

See if this section from the online documentation that can be accessed via the Manual link at the bottom of the unRaid GUI is of any help.

If you are trying to pass through the NVME drive in the way you seem to want then it must NOT be mounted at the Unraid level. Also the formatting will normally happen inside the VM.

There is also the fact that with newer drives the packing density may be higher so that more data can be read in a disk revolution.

That SMART error is probably a red herring as it looks like a single CRC error which is not really significant. When you say that the array has ‘stopped’ what exactly do you mean? Do you mean the server is still running but the array is in a stopped state; the server appears to have crashed or the server itself has shutdown or something else?

Thanks for those files. I can see from the .cron file that the cron job entry that should have been scheduled for scheduled pause/resume seems to not be present even though the .cfg file shows it is configured at the plugin settings. This also shows why enabling unscheduled checks “appears” to sort of work as that is being picked up by a monitor task that runs once an hour. I say “appears” as it would not run exactly at the time set in the settings for pause/resume as it would if the cron entries were correct. That gives me enough information to make sure that the problem will not be present in my next update. EDIT: I have just done a test on my development 6.8.3 system and if you go into the plugin settings and make a change (can then change it back) and hit Apply you should get the correct entries in the parity.tuning.cron file. If would like to know if that has worked for anyone currently getting unexpected behaviour.

I will try and work out if there is a reason that checks may not be pausing. If anyone is able to enable the “Testing” level of logging and can then let me have the syslog covering the period it will give me more to work with. In addition the various ‘parity.tuning.*’ style files in the plugin’s folder on the flash drive might help. It is possible I have already inadvertently fixed whatever is causing this behaviour as I have done a major re-factoring of the code internal to the plug-in as part of getting ready to release the first version of what I am calling the “Parity Problems Assistant” option. This gives the ability to do partial parity checks over a user defined range to help those who get errors reported during parity checks.

At that level I personally would just ignore them. It is when you start getting many every day that you need to be concerned.

There are 2 things that affect speed: the slowest disk in those currently being actively checked disks slow down as they move from outer to inner tracks It is therefore normal to see the speed gradually slowing due to #2 and then perhaps speed up again due to #1 as the check gets beyond the end of some of the smaller (typically slower) disks.

A non-correcting check will not be a reason for aborting. It would just mean that the same errors will show up each time you run the check until you have successfully run a correcting check.

An occasional error of that type is not really something to worry about x it just indicates a transfer failed a CRC check and got retried. If they occur regularly then you may have a cabling issue. Note the counts never gets reset to zero - they can only increase so if they are stable do not worry.

Not sure what your problem is, but the plugin would not be automatically starting or aborting the parity check - it is just reporting what it thinks has happened. According to the syslog the parity check was manually cancelled.

Yes - but you need a new feature introduced in 6.9.0 releases to use this option.