itimpi

If you are writing directly to the array then the speed is constrained by the overheads of updating the parity disk as explained here in 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. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

That is unlikely to be big enough to be of any practical use.

That looks like a failure reading the flash drive. You could try this to see if it helps.

You could also have fixed the templates for the affected containers.

Ideally the user should never set up hard coded references in the first place, particularily with the 6.12.x releases and the Introduction of Exclusive shares which have the same performance characteristics as these hard coded references. Unraid silently changing anything is highly undesirable because the user may have deliberately set things up a particular way and does not want it over-ridden.

I think the terminology should be changed from Subscription pricing to Update pricing as it better reflects what is being proposed and has less negative connotations for most people

Do you have any spare Molex connectors on the PSU so you could instead use some Molex->SATA splitters?

Correct - the array had to be stopped. The value on User Shares is primarily intended to control when you have a User Share that spans multiple array drives so Unraid knows the threshold for switching to the next drive to be used by the share.

Probably need to wait for @JorgeB to give you best advice on how to recover from this. That is the basic idea, but you have to specify the cutover point. Set the Minimum Free Space value for the pool to tell Unraid when to switch to by-passing the pool before it gets filled up too far.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. It could be worth enabling the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

With that many reallocated sectors I am surprised the disk is still functioning 😇

Note that you should always have a backup elsewhere of anything important or irreplaceable as parity us all about protecting against physical disk failure and does not protect against other ways of losing data.

Noticed some very strange settings for the Parity Check Tuning plugin where it is set to resume at 0:15 and pause at 0::30 - a total runtime of only 15 minutes. Mentioned this as one of the last things that happened seemed to be a parity check running. Can your PSU reliably handle the load of all drives being active at the same time?

You should not need these with modern drives - they should be able to reallocate these sectors instead. Marking bad sectors is a hangover from the days of IDE drives.

The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

Does. It look like the array was started when the posted diagnostics were taken?

The error message indicates that the batch file was looking for the syslinux.exe on the C drive - not the flash drive. Normally if you run the file by right-clicking and then selecting "Run as Administrator" the flash drive will be the current drive within the batch file.

Looking at the Windows error it looks as if you did not switch the flash drive before running the make-bootable.bat file as that is where the syslinux.exe file is located.

It should not have mattered that you were having crashes. The trigger for the error message you were getting (which was meant to be fixed in the last plugin update) was exactly you having a crash during a parity check that was manually initiated. It is quite possible that you shutting down tidily meant that these conditions were not met. That is why I am interested in seeing if you can get it again in the future and what leads up to it.

Thanks. According to those diagnostics the state information WAS cleared up during the boot sequence and you are no longer getting those error messages from the plugin. If by any chance you manage to get this symptom again then I would appreciate if you can provide any information about what you might have done to create it and if possible any new diagnostics taken at the time.

First time I have heard of this ☹️ I would suggest you post your system's diagnostics zip file taken after this has occurred in your next post in this thread to see if we can spot anything and get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

If you want to clear them after replacing them then pre-clear can do the job. You would only need the write cycle for this. However keep them intact until you have checked that a replacement appears to have completed without error as this gives you a fallback if problems are encountered.

Cannot see from your description any obvious reason why the files should not be visible. I suggest you should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

Replacing disks to increase capacity is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release. Note that you have to upgrade the parity disk first as no data drive can be larger than the smallest parity drive. Also, you do not have to erase the disks first as the procedure overwrites every sector on the drives anyway. The only reason to run a preclear would be to carry out a stress test of the drives.

They can be ignored as they are an internal check simply reporting a state I did not think would occur. You could delete the parity.check.tuning.automatic and parity.check.tuning.manual file from the plugins folder on the flash drive to stop them being reported. They should also have been removed during a boot sequence as you are on the latest release of the plugin. Have you rebooted since it was installed? If so although this is a different issue I would appreciate it if you could turn on the 'testing' mode of logging in the plugin's settings; reboot the server and then post new diagnostics taken after the reboot so I can see if I can determine why this was not tidied up during the reboot.