JorgeB

Remove the existing partitions by clicking on the red x then format.

What release are you using? AFAIK all spin down related issues are fixed in the latest -rc, my issues were fixed.

You need to enable destructive mode in the UD settings to format disks, I would just use XFS, they can always be read in any Linux computer, or by using an Unraid trial key.

May 3 05:13:01 smashboogie kernel: macvlan_broadcast+0x116/0x144 [macvlan] May 3 05:13:01 smashboogie kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Yes, if they are in a pool now: btrfs balance start -f -mconvert=single /mnt/pool_name

Likely they are symlinks and it's this issue:

That looks like a BIOS issue, look for an update.

If it's still slow also a good idea to run a test with the diskspeed docker to make sure all disks are performing normally.

Enable mover logging, run the mover, post new diags.

Rebooting will clear that, you might want to save the diags before doing in case they are needed, and if the log keeps growing you should post new diags.

Cache device dropped offline before: May 5 22:39:19 BIGDADDY kernel: ata1: hard resetting link May 5 22:39:24 BIGDADDY kernel: ata1: COMRESET failed (errno=-16) May 5 22:39:24 BIGDADDY kernel: ata1: reset failed, giving up May 5 22:39:24 BIGDADDY kernel: ata1.00: disabled May 5 22:39:24 BIGDADDY kernel: ata1: EH complete All the btrfs errors are the result of that, if it happens again replace the cables.

Onboard SATA is set to IDE, change to AHCI and try again.

That basically rules out any CPU issues, disks seem to be performing well so my main suspect for me would be the controller, not a bandwidth issue but some driver/compatibility issue, that controller is kind of an unknown since there aren't many used with Unraid.

It should be using a standard LSI IT firmware, in the link shows how to list current firmware, post the output here.

Agree

Issues with disk2 now, so possibly the problem are the cables that were swapped there from disk1, you should replace them.

Appdata exists on both disk1 and cache, move everything to cache, with the current setting files on that folder are being moved from cache to disk1 and depending on the mappings, i.e., if you use /mnt/cache/appdata instead of /mnt/user/appdata there will be missing files for the apps.

This happened to me before, and it can happen with parity, usually easily fixable, just no clear why a balance is running, if it started automatically post the diagnostics to see why.

I don't know why the logs aren't showing the boot process from the start, I can't even see the HBA firmware version, but they are still filled with HBA errors, see if it's using the latest firmware, if not upgrade.

It means the plugin is crashing.

Strange, if it was a power/HBA issue I would also expect issues during a parity check.

Both times there are some LSI HBA related error messages, those by itself should not a reason for Unraid to crash, but they could be the result of a hardware issue, like bad power, writing will require more power than reading, or a problem with the HBA, have you tried running a parity check to see if it also crashes?

That firmware doesn't have any major issues AFAIK, but you should always upgrade to the latest, instructions here.

Yep, IMHO servers and overclocking never really go well together, and running 2133 and 2400 rated DIMMs @ 3200MT/s is pushing your luck

Syslog starts over after every reboot, enable the syslog server and post that together with the full diagnostics after a crash.