JorgeB

You should free up some space, then convert to single, or the balance might fail.

Using onboard SATA ports + HBA if needed. Should be OK, but some USB enclosures create a custom partition or use a custom ID that might not be recognized by Unraid on a SATA port, it should still work with UD if needed.

Cache is completely full, it's also using dual data profiles, you should get a notifications about that (if enable), you need to free up some space and balance it.

Yeah, not sure about this also.

The trim itself is the command, behavior after trim depends on the device.

Yes, all appears to be OK with the pool, don't know where the notification comes from.

From what I remember besides the SATA controller it was only passing-trhoug a USB controller and a GPU, so it should be fine, but you should check.

It's not up to the controller, if up to the device (for SATA): https://en.wikipedia.org/wiki/Trim_(computing)#ATA NVMe devices are different.

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