JorgeB

Realtek NIC Linux drivers have been notoriously buggy, for many years, next release might have a newer/better one, but best bet would be to use an Intel NIC if possible.

Parity can't fix filesystem corruption, you need to run xfs_repair.

Parity swap is mainly for when you have a data disk disable and the spare is larger than current parity, it can be used to replace a healthy disk, but there aren't many advantages, it will take about the same time, and the array will be offline for hours during the parity copy portion, it could be considered an advantage the fact it only needs to read from all disk once, unlike twice with the normal upgrade method.

It's in the link above.

In the BIOS, make sure it's up to date.

Did you also change the power supply idle control?

Should be fine.

Not possible since that's a 2 port controller, others are likely using the Intel SATA ports.

If all the hardware supports hot swap yes.

Take a look here, at the idle power setting and at the officially supported RAM speeds, you are overclocking the RAM for your CPU, it's a known issue.

Both cache devices dropped offline at the same time: Oct 12 23:47:21 fractal kernel: ata7: hard resetting link Oct 12 23:47:56 fractal kernel: ata7: softreset failed (1st FIS failed) Oct 12 23:47:56 fractal kernel: ata7: limiting SATA link speed to 3.0 Gbps Oct 12 23:47:56 fractal kernel: ata7: hard resetting link Oct 12 23:47:56 fractal kernel: ata8: softreset failed (1st FIS failed) Oct 12 23:47:56 fractal kernel: ata8: limiting SATA link speed to 3.0 Gbps Oct 12 23:47:56 fractal kernel: ata8: hard resetting link Oct 12 23:48:01 fractal kernel: ata8: softreset failed (1st FIS failed) Oct 12 23:48:01 fractal kernel: ata8: reset failed, giving up Oct 12 23:48:01 fractal kernel: ata8.00: disabled Oct 12 23:48:01 fractal kernel: ata8: EH complete Oct 12 23:48:01 fractal kernel: ata7: softreset failed (1st FIS failed) Oct 12 23:48:01 fractal kernel: ata7: reset failed, giving up Oct 12 23:48:01 fractal kernel: ata7.00: disabled They are both on the same Asmedia controller, so possibly a controller issue, or a power problem if both share a power connector/splitter. This by itself should not cause data loss, but I can only see cache usage after the reboot, can't see what it was before because the diags are naturally after they both dropped.

Try this and then post that log after a crash.

It's a known issue, update to -beta30

Failed SMART tests can't be caused by cable issues, so it was really a disk problem, though an internement one, I would probably give it a second chance but any more errors or failed SMART tests replace it.

Backup current flash, recreate it using the USB tool, restore only super.dat (disk assignments) and the key file from the backup, both in the config folder.

Try doing the update with just one core assigned to the VM.

Problem with the onboard SATA controller: Oct 12 23:36:45 Jinx kernel: ahci 0000:01:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000da8d0000 flags=0x0000] Quite common with Ryzen boards, there are reports that updating to the latest beta helps, due to newer kernel, you can also disable IOMMU if not needed.

Basically you'd need to rebuild each drive one at a time, more details here:

Are you hot swapping any devices? Several devices disconnecting/reconnecting, cache device (ATA2) dropped offline at that time: Oct 12 14:04:53 Soong kernel: ata1: SATA link down (SStatus 0 SControl 300) ### [PREVIOUS LINE REPEATED 2 TIMES] ### Oct 12 14:05:04 Soong kernel: ata1.00: disabled Oct 12 14:05:04 Soong kernel: ata1.00: detaching (SCSI 2:0:0:0) Oct 12 14:05:04 Soong kernel: sd 2:0:0:0: [sdh] Synchronizing SCSI cache Oct 12 14:05:04 Soong kernel: sd 2:0:0:0: [sdh] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 Oct 12 14:05:04 Soong kernel: sd 2:0:0:0: [sdh] Stopping disk Oct 12 14:05:04 Soong kernel: sd 2:0:0:0: [sdh] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 Oct 12 14:05:04 Soong rc.diskinfo[10491]: SIGHUP received, forcing refresh of disks info. Oct 12 14:05:04 Soong kernel: ata3: SATA link down (SStatus 0 SControl 300) ### [PREVIOUS LINE REPEATED 2 TIMES] ### Oct 12 14:05:16 Soong kernel: ata3.00: disabled Oct 12 14:05:16 Soong kernel: ata3.00: detaching (SCSI 4:0:0:0) Oct 12 14:05:16 Soong kernel: sd 4:0:0:0: [sdj] Synchronizing SCSI cache Oct 12 14:05:16 Soong kernel: sd 4:0:0:0: [sdj] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 Oct 12 14:05:16 Soong kernel: sd 4:0:0:0: [sdj] Stopping disk Oct 12 14:05:16 Soong kernel: sd 4:0:0:0: [sdj] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 Oct 12 14:05:16 Soong rc.diskinfo[10491]: SIGHUP received, forcing refresh of disks info. Oct 12 14:05:24 Soong kernel: ata2: SATA link down (SStatus 0 SControl 300) ### [PREVIOUS LINE REPEATED 1 TIMES] ### Oct 12 14:05:34 Soong kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Oct 12 14:05:34 Soong kernel: ata1.00: ATA-10: ST4000DM004-2CV104, ZFN1JR8M, 0001, max UDMA/133 Oct 12 14:05:34 Soong kernel: ata1.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32), AA Oct 12 14:05:35 Soong kernel: ata1.00: configured for UDMA/133 Oct 12 14:05:35 Soong kernel: scsi 2:0:0:0: Direct-Access ATA ST4000DM004-2CV1 0001 PQ: 0 ANSI: 5 Oct 12 14:05:35 Soong kernel: sd 2:0:0:0: [sdh] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB) Oct 12 14:05:35 Soong kernel: sd 2:0:0:0: [sdh] 4096-byte physical blocks Oct 12 14:05:35 Soong kernel: sd 2:0:0:0: [sdh] Write Protect is off Oct 12 14:05:35 Soong kernel: sd 2:0:0:0: [sdh] Mode Sense: 00 3a 00 00 Oct 12 14:05:35 Soong kernel: sd 2:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oct 12 14:05:35 Soong kernel: sd 2:0:0:0: Attached scsi generic sg7 type 0 Oct 12 14:05:35 Soong kernel: sdh: sdh1 Oct 12 14:05:35 Soong kernel: sd 2:0:0:0: [sdh] Attached SCSI disk Oct 12 14:05:35 Soong kernel: ata2: SATA link down (SStatus 0 SControl 300) Oct 12 14:05:35 Soong kernel: ata2.00: disabled Oct 12 14:05:35 Soong kernel: ata2.00: detaching (SCSI 3:0:0:0)

Correct, just stopping and restarting the array appears to be enough to flush cache, at least the results were consistent with repeat runs, some of them after rebooting, when I changed release used. Multiple directories, these last tests I did this morning used just part of the small files to make it go faster, the smaller ones which I noticed were the ones causing the more significant slowdown, 11.5k files in 74 folders totaling about 50MB, so very small files, and not something most people would ever use with Unraid, I was just curious after the other results, I also tested with direct_io on/off and there was no difference for almost all the tests, hence my earlier question. On the other hand, user shares performed very well with large files, always about the same as using disk shares, on all 3 releases I tested (v6.7.2, v6.8.3 and -beta30).

Yep, and with v6.9-beta1, it only doesn't happen with recent betas.

Not really something that affects me, and I would guess most users, since probably most content archived are medium/large media files, but anything you could do would always be good, since according to some quick tests I did this morning, comparing user vs disk shares with small file writes, it appears to be getting worse with each new release, writing to a disk share was about 170% faster with v6.7, 350% faster with v6.8 and I'm now getting 500% faster with -beta30, and the write speed to a disk share has remain about the same, it's the user share writes that keep getting slower.

Maybe, but the btrfs issue I can reproduce as many times as I want (with -beta1 or earlier) just by changing those values, that suggests it's working no? Or at least it's changing something...

Yep, good option.

Don't know that model, probably an OEM version, but should be similar to the 9300-8i, and that's one of the recommended models.