JorgeB

https://forums.unraid.net/bug-reports/stable-releases/683-docker-image-huge-amount-of-unnecessary-writes-on-cache-r733/?do=findComment&comment=9527

Always possible.

It is, the 16TB is CMR.

No.

All files already on the disks should be fine, if there were any files being written when the controller crashed those are likely corrupt.

Now it's the other NIC, possibly you have some custom IP config that is causing issues, did you check the link above about docker with custom IP addresses?

Only did a quick test but this appears to make a notable difference for me, I tested moving my problem VM to an unassigned device first using the default partition alignment and then align it to 1MiB, watching the i/o stats for 5 minutes writes decreased about three times, performance at least on that device was also noticeably better, still high writes though, but most likely a step in the right direction.

https://forums.unraid.net/topic/93941-cant-connect-to-network-on-new-unraid-build-maybe-ethernet-driver-issue/?do=findComment&comment=868329

You're overclocking the RAM for that CPU, see here, note also the power supply idle control setting, if not yet done.

Check filesystem on disk3: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

1 found corruptions can be fixed only when running with --rebuild-tree Run it again with --rebuild-tree

Yes, but no need to unassign it first, just shutdown, replace disk, power on, assign it and start array to rebuild.

That was true once, but not for some time, it should be updated.

Device is dropping offline: Jun 24 16:13:40 DMS kernel: ata6.00: status: { DRDY } Jun 24 16:13:40 DMS kernel: ata6: hard resetting link Jun 24 16:13:41 DMS kernel: ata6: SATA link down (SStatus 0 SControl 320) Jun 24 16:13:46 DMS kernel: ata6: hard resetting link Jun 24 16:13:47 DMS kernel: ata6: SATA link down (SStatus 0 SControl 320) Jun 24 16:13:52 DMS kernel: ata6: hard resetting link Jun 24 16:13:52 DMS kernel: ata6: SATA link down (SStatus 0 SControl 320) Jun 24 16:13:52 DMS kernel: ata6.00: disabled This is usually a connection problem, replace cables, both power and SATA.

Yes. Check "parity is already valid" before starting the array, next to the start array button.

It's a problem with the onboard SATA controller: Jun 24 23:08:02 QuantumBreak kernel: ahci 0000:02:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x44c2b16d89f81e00 flags=0x0010] Jun 24 23:08:02 QuantumBreak kernel: ahci 0000:02:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x44c2b16d89f81e80 flags=0x0010] This is quite common with Ryzen servers and there are reports that upgrading to v6.9-beta helps because of the newer kernel.

Because it's read-only it can't be easily moved with the mover, but you should still be able to use your favorite utility to copy it, e.g., see here for a way to do it.

Order doesn't matter, but all pool members must be present and assigned.

Iperf performance is usually directly linked to the hardware used, if you can try with Mellanox ConnectX2/3 or Intel NICs, those are know to usually work well and give close to line speed, I use Mellanox on various Unraid servers and get around 9Gbits.

That is usually a bad SATA cable and likely the reason the disk dropped offline earlier, but as long as it doesn't increase anymore it's fine, and it shouldn't if you replaced the cables as suggested.

If they were unassigned after changing the controller the device identifications might have changed, if that's the only change you can re-assign them but only after starting the array without them so Unraid can forget the old pool config, then before re-starting the array you need to re-assign all the pool members and there can't be any "data on device will be deleted at array start" warning, but note that some RAID controllers make changes to the MBR and/or don't use the full partition size in which case the pool would might be unmountable.

1.7GB is very little RAM to run Unraid v6 even as a basic NAS, it should be fine with 4GB.

Best bet it to backup cache, re-format the pool and restore the data.

Last call trace is related to the Mellanox NIC, see if you don't get them by temporarily running without it.

If you have single parity data drive order is not important, parity will still be valid, it's not the same with dual parity, parity1 would still be valid but not parity2.