WizADSL

Could someone please post the smartmon tools output for a Samsung 870 EVO 2TB? Probably any of the variants would be fine (1 TB - 4TB) but the 2TB is the one I'm specifically interested in. If you are looking in the UNRAID web UI I'm specifically looking for the contents of the Identity tab. Thank you.

You may also want to run a memory test.

I tried what is suggested in that post and it didn't make a difference. I did notice the if the disk spins up automatically as a result of accessing data on the drive the error does not appear. The error only seems to occur if the drive is explicitly spun up either by the user or when the array does explicitly it such as when you stop the array.

One-time bump, has anyone seen this before? Thank you.

I've seen some forum topics relating to this error but it seems they were for UNRAID versions prior to 6.9.2. I'm seeing what are probably benign (I hope) errors when drives are spun up on UNRAID 6.9.2. I was recently running 6.8.3 and have only started seeing these errors after the upgrade. Nothing whatsoever has changed beyond the UNRAID version. Diagnostics attached. tower-diagnostics-20210513-1220.zip

I came into the room where Unraid lives and notices the server was off. It's on a UPS and prior to a graceful reboot I did about 45 days ago had run for 377 days without issue. When I powered it back on it looks like some of the CPUs either crashed/panicked or failed to come up. The earlier diagnostics should show this. Because the web interface had stopped responding I had to force a power off. I restarted the system and it looks like it is back up. Obviously a parity check is in progress. I'm still seeing 3 BTRFS errors in the log (see second diagnostics): May 7 03:55:09 Tower kernel: BTRFS error (device sdi1): parent transid verify failed on 2012598697984 wanted 8694591 found 183486155 May 7 03:55:09 Tower kernel: BTRFS error (device sdi1): parent transid verify failed on 2012598697984 wanted 8694591 found 183486155 May 7 03:55:09 Tower kernel: BTRFS error (device sdi1): parent transid verify failed on 2012598697984 wanted 8694591 found 183486155 I would appreciate any advice regarding the BTRFS errors and the initial cause of the crash if anyone has any ideas. Thank you. tower-diagnostics-20210507-0340.zip tower-diagnostics-20210507-0401.zip

Were the drives with the issue originally sold as externals?

I'm seeing this now in 6.8.3 (and for a while now). if I click the close gadget on a notification, the notification disappears for a moment (a second or less) and then reappears. If I refresh the browser after having done that the notification does not return. In my case I use Chrome, perhaps it was a change there?

Maybe we're saying saying different things? If you are running a VM in unraid which is completely separate and isolated from the unraid host then it is the VM's kernel that needs ZFS support. What you are saying would be the as if I said I was going to run a Windows Server 2019 VM in unraid and I wanted to use the ReFS filesystem in that VM then the unraid kernel would need to support it which is unnecessary.

If TRUENAS is running as a VM in UNRAID wouldn't you just want to pass the USB devices through to the VM in the VM configuration? I don't see why you would need ZFS support in the host kernel.

Try: You can try using sfdisk to copy the partition table from one drive to another. I have not tested this personally but it's worth a try although I would make sure you don't have irreplaceable data on the subject disk as I assume this will nuke it. In the command below "sfdisk --dump" will dump the partition table layout of /dev/sdd in a format that the following command (through the pipe) can then write the same layout to /dev/sdv. If you examine the output of the --dump command you can see what will be done and you could proabaly do it "manually" if you prefer. sfdisk --dump /dev/sdd | sfdisk --force /dev/sdv

Ok, so where's Red Dwarf then?

I would recommend disabling any ad blockers when accessing the unraid web interface. I have had problems in the past with this.

Another long shot, have you tried booting EFI?

Based on what was happening with the Sqlite databases, could this have caused corruption in other files on the array?

On 6.8rc1 I am still seeing writes starve reads. I' wondering if these parameters are an issue for me since other have reported that 6.8rc1 has solved the problem for them.

Thank you for that. I'm hoping someone can chime in on the remaining parameters.

is there any guidance available for MD tunables on version 6.8rc1? Does the size or number of discs or system memory affect what the best values would be? In the presence of very high I/O I still have some performance issues and I would like to see if any of the parameters can be adjusted to mitigate that.

Now that we presumably know the source of the corruption do we know if any other type of data would have been affected? Do we know what type of disk activity would have resulted in corruption?

It looks like it's from the Netdata Docker container.

Just wanted to chime in. I've always had my Docker image and configs on the cache drive and never experienced this issue. I've been on 6.7.2 since its release and used most of not all of the affected versions.

No, but that is one of the things he'd like to attempt if he connects it to a monitor in order to do the BIOS upgrade. I would strongly discourage overclocking ANY server let alone one where heat may already be an issue WITHOUT overclocking.

I would definitely update the BIOS. There are a lot of changes/fixes that can be made in the BIOS code which could affect your problem. I WOULD NOT OVERCLOCK ***** ESPECIALLY IF YOU SUSPECT HEAT IS AN ISSUE -NOW- *****

Have you considered upgrading you MB BIOS? The diagnostics you posted show you are running version 0402 dated 06/13/17 and version 1902 dated 07/19/2019 is available.

Do you know if your power supply is properly sized and healthy? I've had problems in the past that would only appear during a parity check (all drives spinning) because the power supply was of the proper capacity but had become weak over time and didn't have any noticeable issues until it had a higher load on it.