JorgeB

Likely won't make much (if any) difference but since surveillance drives are optimized for write intensive workloads I would probably use it as parity.

I have to go now, someone else should be able to help you if still needed, but I'll check back tomorrow.

It's showing as duplicate UUID, which suggest it didn't unmount successfully, reboot the server and all should be OK, then run the parity check.

NEVER format, did you unmount it from UD before starting the array? If not do that (and re-start the array), if yes post new diags.

OK, check contents and make sure data looks correct, look for any lost files/folders inside a lost+found folder, if everything looks good assign disk 3 to the array, all disks should still be new (blue icon), if yes check "parity is already valid" and start the array, then run a correcting parity check since a few sync errors are expected.

When attempting to mount again no need for read-only mode anymore.

On the console/terminal type: xfs_repair -v /dev/sde1 If it asks for -L use it: xfs_repair -vL /dev/sde1 When done try to mount it again.

That suggests it didn't mount, please post the diagnostics: Tools -> Diagnostics P.S. I'll be leaving for the day in a few minutes so if you can reply fast.

Yes, try that, also check/replace power cable, without full diags it's difficult to say more.

LSI 9200 (or Dell H200) is PCIe 2.0, LSI 9207 is PCIe 3.0

Tools -> Diagnostics

You can post the diags grabbed after or during a transfer, there might be some clues there.

It should mount now if you start the array.

No.

Good you found the issue, if you don't mind I'm going to tag it solve. Edit: I see you already did it.

It can also be the rsync command, e.g. if it's using compression, but that's unlikely assuming you're using the same as before.

So the enclosure is likely the problem.

Not necessarily since there were also writes to other data disks that made old parity out of sync, still a filesystem check might be enough to recover the old or a rebuilt disk, in any case you need to do a new config first: -Tools -> New Config -> Retain current configuration: All -> Apply -Assign correct parity drive in place of current disk3 -Leave the array like that for now, don't start it. Now before re-assigning old disk3 you want to make sure it's still mounting, see if it mounts with UD (use read-only option) then post results so we can decide best course of action.

Gigabit network transfer should give you around 110MB/s, if you get that it points to an enclosure issue, if you get the same 30MB/s it's likely an array issue, it gives us an idea where to start looking for the problem.

NEVER formatting, unassign the disk, start the array, emulated disk is likely still going to be unmountable, if yes run xfs_repair on the emulated disk. though there's a small possibility the emulated disk could mount from start if the actual disk really has a problem.

Testing the speed using the network would rule out an enclosure issue, or confirm an array problem, either way it would be an easy thing to do.

Why would it be slower? Are using 100Mbit or Wifi?

It does look like a disk problem, thought the ATA errors are not logged as media errors, but adding the weird noises and reallocated sectors it points to that, you could unassign that disk, then attempt to fix the filesystem on the emulated disk, if successful rebuild to a new disk.

Please post current diags just to see if there's any disk read error, either that or it's a xfs_repair issue.

Run without -n or nothing will be done.