itimpi

First time I have heard of it! normally corruption is rather more obvious in that non-ascii characters appear. Removing a line is an unexpected form of corruption.

Just pushed a release with quite a few small fixes: - New: Remove support for Unraid versions prior to 6.9.2 - New: Add warning about incompatibility with Unraid Cumulative Parity Check option. - Fix: History button on Settings page not working for Unraid 6.11 and 6.12 - Fix: Extended Parity History on not being displayed from Main screen - Fix: After restart was not pausing if outside increment time slot. - Fix: If increment type not being monitored and paused before reboot was not re-instating pause on restart - Fix: Updates to make master translation file agree with current plugin. - Fix: Improve some of the code to better handle array not yet started. - Fix: Remove code that failed to spin up drives and leave it to Unraid to do this. Hopefully I have not broken any existing working functionality If anyone spots any anomalies then please let me know.

There should only be 1 append line with all the options on the same line space separated.

A format command simply rewrites the control structures, and does not overwrite the actual data blocks. Since the disk was in reiserfs format then you might just be able to recover much of the data by running reiserfsck against it with appropriate parameters Cannot hurt to try at this stage. I think the relevant command would be: reiserfsck --scan-whole-partition --rebuild-tree /dev/md7 but you might want to see what someone else thinks. Note that this command would take hours to run so do not expect any quick results. another possibility might be disk recovery software such as UFS Explorer.

Cannot even see the USB enclosure being detected I would suggest carefully checking power and cabling to it. If possible you might try plugging it temporarily into another machine if available to see if that detects it.

I would definitely try the USB2 port as experience has shown them to be far more reliable than USB3 ones. If it works on the external USB2 port then I see that board also has USB2 headers that you could use if you prefer the drive to be internal. I also recommend (if possible) a USB2 based flash drive although they are now getting a bit harder to source as they also seem to work more reliably if you only have USB3 sockets available. on paper USB3 feels like it should be a better solution but experience has shown this is often not the case although it could change as the technology gets better and uSB3 support improves.

According to the diagnostics it appears that your cache drive has dropped offline (which would explain the dockers not working). I would carefully check and power and SATA cabling to the drive.

Follow the link

Are you using one of the USB2 ports on your motherboard (possibly via internal header) for the flash drive as they tend to be more reliable than USB3 ports. Alternatively can you use a USB2 flash drive as you get no noticeable performance advantage from using a USB3 one.

Your syslog is full of errors on the sdb device (cache2) so that is the likely cause of your problem. Not sure though of the best way to proceed - hopefully @JorgeB as the expert on these things will chime in.

If the diagnostics are taken when in the error state they may give a clue so you should then post them to your next post in this thread. If only after a reboot then you should enable the syslog server to get a syslog that survives a reboot.

The speeds seemed quite reasonable when there was nothing writing to the array drives so not sure that there is an easy fix for this. I have no idea though why your VMs and/or Docker containers cannot run while a parity check is running as the critical shares for performance (appdata, system) do not seem to have files on the array. At the moment I have no further ideas on this I am afraid. Maybe someone else might chime in with an idea. Do you have the syslog server enabled so that you have a syslog that covers the whole shutdown and reboot process? It does seem to be the most important issue though as if you could stop this happening so you would only get parity checks when you wanted/scheduled them they would be less painful.

There is no reason that a parity check should stop those working, although their performance might suffer if they try to access files on the main array.

The latest diagnostics show that an unclean shutdown was still detected Feb 8 06:31:25 NAS01 emhttpd: unclean shutdown detected If as you say you stopped the array before the reboot then this suggests that Unraid might have had problems with writing back to the flash drive that the array had been successfully stopped. Have you had any issues with the flash drive?

The diagnostics showed that the ‘go’ file had the line that starts up the GUI missing. Are you sure you did not accidentally delete that as the file otherwise has sensible contents and simply having a line deleted is not what one might expect from corruption?

What makes you think that the shares will not spread to the other drives? With the default allocation method of High Water this will start happening when there is 4TB used on the first drive.

Which solution are you using? Is that using the My Servers plugin or the WireGuard VPN.

Have you got the right breakout cables I wonder? Forward and Reverse break-out cables look identical but only the correct ones work to show the drives.

You will be able to get away with USB if you forgo the use of a parity drive. Although disks can still drop offline a reboot gets them back.

You need to give a good Use Case where the Parity Swap procedure would not be sufficient.

The drive selection is done at a low level when the file is first created (and thus has 0 size) and that level has no knowledge of the final size of the file.

Yes. Split Level over-rides all other selection criteria if there is any contention about which drive to use. If you use restrictive Split Level settings then you need to monitor free space on drives a bit more carefully. probably the best avoidance action is to set the warning levels for each drive to be sufficient to give you time to consider moving some files to another drive (dtive-to-dtive moves bypass User Share settings).

You have to upgrade the parity disk before you can add larger data disks as no data disk can be larger than the smallest parity disk. If you have a failed data drive you can use the Parity Swap process to simultaneously upgrade the parity drive to 8TB and then reuse the old 4TB parity drive to replace the failed data drive.

I can not see any sign of the LSI card showing up at the hardware level in the diagnostics. have you managed to validate the card is working in any way? Have you tried a different PCIe slot? Can you access the card at the BIOS level? can you see the drives at the BIOS level?

This is what I would expect as you if you were able to pass thru a mounted drive it would immediately start erroring.