JorgeB

SMART is showing some issues, you should run an extended test.

Yes, this is normal with reiser, very large filesystems can take more than an hour to mount after a dirty shutdown.

With Unraid you have "user shares" and "disk shares", disk shares will share all array devices as individual disks, e.g. \\tower\disk1, etc, and all pools, e.g., \\tower\cache or \\tower\yourpool, are you having trouble accessing a user share on the pool or you want to export the pool itself as a share?

This is a SATA controller. This one:

You can for example disable NIC bonding.

Those are all very similar and a good choice for Unraid.

Changed Status to Closed

Most likely, it's been a while since I tested.

Yes, two disabled drives.

Most likely the result of the enclosure used, try a different one if available.

Please don't crosspost, pasting reply from your other thread: If it's slow from the beginning of the transfer it suggests a network issue, start by running a single stream ipert test.

Disks 1 and 2 got dropped: Dec 12 23:14:14 v1ew-s0urce kernel: ata3.00: disabled Dec 12 23:14:14 v1ew-s0urce kernel: sd 3:0:0:0: [sdb] Synchronizing SCSI cache Dec 12 23:14:14 v1ew-s0urce kernel: sd 3:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 Dec 12 23:14:14 v1ew-s0urce kernel: sd 3:0:0:0: [sdb] Stopping disk Dec 12 23:14:14 v1ew-s0urce kernel: sd 3:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 Dec 12 23:14:14 v1ew-s0urce kernel: ata4.00: disabled Dec 12 23:14:14 v1ew-s0urce rc.diskinfo[8888]: SIGHUP received, forcing refresh of disks info. Dec 12 23:14:14 v1ew-s0urce kernel: sd 4:0:0:0: [sdc] Synchronizing SCSI cache Dec 12 23:14:14 v1ew-s0urce kernel: sd 4:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 Dec 12 23:14:14 v1ew-s0urce kernel: sd 4:0:0:0: [sdc] Stopping disk Dec 12 23:14:14 v1ew-s0urce kernel: sd 4:0:0:0: [sdc] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 Because you're passing-though their controller to a Windows VM: -device vfio-pci,host=0000:06:00.0,id=hostdev0,bus=pci.9,addr=0x0 \

If it's not the RAM it will be harder to track down, it can be controller, board/CPU or just one of the disks, see here for some troubleshooting tips on a recent case.

Yes, and since you already did I'm going to close this one.

Like mentioned in the FAQ if the options there don't work best bet is to use the btrfs mailing list and/or their IRC channel for help.

Diags after rebooting are not much help, you can try this and post that log after a crash.

The module mentioned in the call trace: nf_nat_ipv4

Driver is crashing during NIC initialization: Dec 13 12:08:34 Tower kernel: ------------[ cut here ]------------ Dec 13 12:08:34 Tower kernel: WARNING: CPU: 5 PID: 1641 at net/ethtool/common.c:373 ethtool_check_ops+0xe/0x16 Dec 13 12:08:34 Tower kernel: Modules linked in: wmi_bmof intel_wmi_thunderbolt mxm_wmi x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel btusb btrtl btbcm btintel crypto_simd cryptd glue_helper bluetooth rapl intel_cstate tn40xx(O+) ecdh_generic i2c_i801 intel_uncore ahci input_leds ecc i2c_smbus igc i2c_core libahci led_class video wmi thermal fan backlight button acpi_pad Dec 13 12:08:34 Tower kernel: CPU: 5 PID: 1641 Comm: udevd Tainted: G O 5.9.13-Unraid #1 Dec 13 12:08:34 Tower kernel: Hardware name: ASUS System Product Name/ROG STRIX Z490-E GAMING, BIOS 0707 07/21/2020 Dec 13 12:08:34 Tower kernel: RIP: 0010:ethtool_check_ops+0xe/0x16 Dec 13 12:08:34 Tower kernel: Code: 42 c2 eb ec 41 89 45 00 48 89 ef e8 19 65 b8 ff 5b 44 89 e0 5d 41 5c 41 5d 41 5e c3 31 c0 48 83 7f 78 00 74 0c 83 3f 00 75 07 <0f> 0b b8 ea ff ff ff c3 48 8b 97 38 08 00 00 31 c0 49 89 f8 b9 0b Dec 13 12:08:34 Tower kernel: RSP: 0018:ffffc90000afba68 EFLAGS: 00010246 Dec 13 12:08:34 Tower kernel: RAX: 0000000000000000 RBX: 000000000043a400 RCX: ffff888849c546d0 Dec 13 12:08:34 Tower kernel: RDX: ffffffff8209ce20 RSI: ffffc900005b1270 RDI: ffffffffa033d000 Dec 13 12:08:34 Tower kernel: RBP: ffff88884865b000 R08: 0000000000000005 R09: 0000000000000005 Dec 13 12:08:34 Tower kernel: R10: 0000000000000246 R11: 0000000000000054 R12: 00000000fffffffc Dec 13 12:08:34 Tower kernel: R13: ffffffff8209b240 R14: 0000000000000001 R15: ffff88884865b000 Dec 13 12:08:34 Tower kernel: FS: 000014e1c91a4bc0(0000) GS:ffff88884db40000(0000) knlGS:0000000000000000 Dec 13 12:08:34 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dec 13 12:08:34 Tower kernel: CR2: 000000000065d6e8 CR3: 0000000845494003 CR4: 00000000007706e0 Dec 13 12:08:34 Tower kernel: PKRU: 55555554 Dec 13 12:08:34 Tower kernel: Call Trace: Dec 13 12:08:34 Tower kernel: register_netdevice+0x84/0x47a Dec 13 12:08:34 Tower kernel: ? QT2025_mdio_reset+0x3b5/0x3c4 [tn40xx] Dec 13 12:08:34 Tower kernel: register_netdev+0x1f/0x2e Dec 13 12:08:34 Tower kernel: bdx_probe+0x895/0xaad [tn40xx] Dec 13 12:08:34 Tower kernel: local_pci_probe+0x3c/0x7a Dec 13 12:08:34 Tower kernel: pci_device_probe+0x140/0x19a Dec 13 12:08:34 Tower kernel: ? sysfs_do_create_link_sd.isra.0+0x6b/0x98 Dec 13 12:08:34 Tower kernel: really_probe+0x157/0x32a Dec 13 12:08:34 Tower kernel: driver_probe_device+0x63/0x92 Dec 13 12:08:34 Tower kernel: device_driver_attach+0x37/0x50 Dec 13 12:08:34 Tower kernel: __driver_attach+0x95/0x9d Dec 13 12:08:34 Tower kernel: ? device_driver_attach+0x50/0x50 Dec 13 12:08:34 Tower kernel: bus_for_each_dev+0x70/0xa6 Dec 13 12:08:34 Tower kernel: bus_add_driver+0xfe/0x1af Dec 13 12:08:34 Tower kernel: driver_register+0x99/0xd2 Dec 13 12:08:34 Tower kernel: ? bdx_tx_timeout+0x2c/0x2c [tn40xx] Dec 13 12:08:34 Tower kernel: do_one_initcall+0x71/0x162 Dec 13 12:08:34 Tower kernel: ? do_init_module+0x19/0x1e0 Dec 13 12:08:34 Tower kernel: ? kmem_cache_alloc+0x108/0x130 Dec 13 12:08:34 Tower kernel: do_init_module+0x51/0x1e0 Dec 13 12:08:34 Tower kernel: load_module+0x141c/0x1fac Dec 13 12:08:34 Tower kernel: ? map_kernel_range_noflush+0x27b/0x2fe Dec 13 12:08:34 Tower kernel: ? __do_sys_init_module+0xc4/0x105 Dec 13 12:08:34 Tower kernel: ? _cond_resched+0x1b/0x1e Dec 13 12:08:34 Tower kernel: __do_sys_init_module+0xc4/0x105 Dec 13 12:08:34 Tower kernel: do_syscall_64+0x5d/0x6a Dec 13 12:08:34 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Dec 13 12:08:34 Tower kernel: RIP: 0033:0x14e1c980609a Dec 13 12:08:34 Tower kernel: Code: 48 8b 0d f9 7d 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c6 7d 0c 00 f7 d8 64 89 01 48 Dec 13 12:08:34 Tower kernel: RSP: 002b:00007fffa952abd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af Dec 13 12:08:34 Tower kernel: RAX: ffffffffffffffda RBX: 000000000065e8f0 RCX: 000014e1c980609a Dec 13 12:08:34 Tower kernel: RDX: 000014e1c98e697d RSI: 00000000000aed50 RDI: 0000000000e958c0 Dec 13 12:08:34 Tower kernel: RBP: 0000000000e958c0 R08: 000000000064701a R09: 0000000000000004 Dec 13 12:08:34 Tower kernel: R10: 0000000000647010 R11: 0000000000000246 R12: 000014e1c98e697d Dec 13 12:08:34 Tower kernel: R13: 00007fffa952b140 R14: 000000000064e1b0 R15: 000000000065e8f0 Dec 13 12:08:34 Tower kernel: ---[ end trace 96cf879c9972755d ]--- Dec 13 12:08:34 Tower kernel: tn40xx: register_netdev failed Dec 13 12:08:34 Tower kernel: ------------[ cut here ]------------ You should create a bug report.

Crash appears to be network related, try to simply the config as much as possible.

btrfs balance start -dconvert=single /mnt/cache

If you haven't yet reboot to clear the log.

You can force a new rebuild to see if no more errors.

Disk3 dropped offline: Dec 12 12:45:27 WattsTower kernel: usb 4-2: USB disconnect, device number 2 Dec 12 12:45:27 WattsTower kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache Dec 12 12:45:27 WattsTower kernel: print_req_error: I/O error, dev sda, sector 87851080 Dec 12 12:45:27 WattsTower kernel: md: disk3 read error, sector=87851016 Dec 12 12:45:27 WattsTower kernel: md: disk3 read error, sector=87851024 Dec 12 12:45:27 WattsTower kernel: md: disk3 read error, sector=87851032 Dec 12 12:45:27 WattsTower kernel: md: disk3 read error, sector=87851040 We don't recommend using USB for array devices, as they are known to drop a lot and bad at error handling.

Disk dropped offline so there's no SMART report, check/replace cables and post new diags.

SMART is showing some issues, you should run an extended SMART test on the disabled disk.