JorgeB

No idea them, sometimes a little slowdown with a new release is normal, but not like that, lets see if other users with similar hardware have the same issue.

If you're copying manually you'll get an IO error, if it's the mover it will fail to move those files and log it in the syslog, if mover logging is enable.

Yep, missed that, you need to unbind the HBA.

LSI is failing to initialize, best to downgrade back to v6.8 for now and try again with a future release, it might have a newer driver that woks best for you, you're not the first with issues, there's another user with two LSI HBAs and only one them works with v6.9.

This confirms it's not a v6.9 issue, strange though, the LSI is detected on the devices and the driver is loaded but it's never initialized, make sure it's well seated or try a different slot if available.

Does it clear the read/write stats but not the errors? If so the behavior might have been changed on purpose, not sure, you can always reboot to clear them, but if you get regular errors there's a more serious issue and it should be fixed.

All the LSI controllers are linking at normal speed/with so it's not that, there's a high load on the server though, if you shutdown all dockers/VMs does it help?

That's weird, did you copy/paste? If yes don't, sometimes the forum introduces extra characters.

After rsync is done run it again, it will only try to copy the missing files.

Nothing jumps out, on the console please type: lspci -vv > /boot/lscpi-vv.txt Then attach the file here.

Note that it will still continue to grow with use.

If reallocated sectors keep increasing you should replace the disk, disks shouldn't corrupt data even when they are failing, but it's been known to happen. Yep. That's another way of confirming the data corruption. You can do a parity swap, use the new disk for parity and old parity for disk2. You can use xfs or btrfs, data will still corrupt if there's a problem, you just won't be warned about it, for the copy I would personally use rsync, it allows resume if needed: rsync -av /mnt/disk2/ /mnt/disks/UD_disk_name/

It's growing but it's not being reported, like mentioned if they are Windows VMs see the link to enable trim, if other OSes see if you can do the same, for a temporarily solution you can copy the vdisks with cp --sparse=always, then delete old one(s).

There's metadata corruption, you need to copy what you can to another place and re-format that disk, corruption like that suggests an underlying hardware problem.

Do you have vdisks?

Start by running a single thread iperf test to check network bandwidth.

Yes. It's by file, it you have 4 x 20GB files and the minium free space is set to 50GB it will successfully copy the 1st two and then you'll get a not enough space error, if the split level set requires the same disk.

Disk2 is showing data corruption, and the balance fails because of that, first see if you can cancel the balance, stop array, start array and immediately after array start type on the console: btrfs balance cancel /mnt/disk2 If it stops then run a scrub on that disk to identify the corrupt data, if it doesn't post back and I'll post instructions to do it with the array stopped.

SMART test passed so replace/swap cables to rule the out and see if it happens again.

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

You should have a format option on the bottom of the main page next to start/stop buttons, if you don't please post a GUI screenshot.

Diags after the problem might give a clue.

Diags show a different thing: Filesystem Size Used Avail Use% Mounted on /dev/md8 3.7T 3.7T 48M 100% /mnt/disk8

An unusually large disk? Shucked disks can sometimes have a different size, but they are usually a little smaller, don't remember ever seeing a slightly larger disk.

Split level always overrides allocation settings, you need to either lower the split level or delete/move the existing folder(s).