JorgeB

Run a scrub and if all errors are corrected re-set the pool, to do that: Stop the array, if Docker/VM services are using the cache pool disable them, unassign all cache devices, start array to make Unraid "forget" current cache config, stop array, reassign all cache devices (there can't be an "All existing data on this device will be OVERWRITTEN when array is Started" warning for any cache device), re-enable Docker/VMs if needed, start array.

If you didn't start the array without it it should still accept both devices, but if it doesn't best to just leave the known good one, if all is well after array start, them wipe and re-add the other one.

Any unclean shutdown since last check?

This.

Start by running a scrub. more info here.

Try moving them manually with Midnight Commander (mc in the console)

According to the log the file don't exist, e.g.: Nov 2 16:11:22 Jukes-Server root: Specified filename /mnt/cache/appdata/PlexMediaServer/Library/Application Support/Plex MediaServer/Media/localhost/9/da299653fd563c25f541c394bc2270f80baec3c.bundle/Contents/Subtitles/pb/com.plexapp.agents.opensubtitles_f15e94a95a4ddd1d700c6bda094772e6fd3e4bf5.srt does not exist. Nov 2 16:11:22 Jukes-Server move: move: file /mnt/cache/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Media/localhost/9/da299653fd563c25f541c394bc2270f80baec3c.bundle/Contents/Subtitles/pb/com.plexapp.agents.opensubtitles_f15e94a95a4ddd1d700c6bda094772e6fd3e4bf5.srt Nov 2 16:11:22 Jukes-Server move: move_object: /mnt/cache/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Media/localhost/9/da299653fd563c25f541c394bc2270f80baec3c.bundle/Contents/Subtitles/pb/com.plexapp.agents.opensubtitles_f15e94a95a4ddd1d700c6bda094772e6fd3e4bf5.srt No such file or directory Not sure what would cause that, assuming the file does exist.

LSI is a good option, number of devices it supports without an expander is in the model, e.g., 4i=4 internal devices.

That's not the full syslog, please post diags instead.

Probably related to this:

Then

Yeah, missed the low usage, mostly likely fs overhead, but easy to check if there's anything still there.

We'd need to see the log, with mover logging enable.

Usually it's plug'n play.

It should speed up significantly once it get past the 4TB disks, so best to wait until it finishes.

Then try swapping cables with a disk using a different controller.

Anything that is working can go bad at any time.

Can't see anything about that in the log due to spam from the cache issue, but USB connections are notoriously unreliable.

Looks more like a connection issue, but if the problem remains after swapping cables and controller it could be the disk, worth trying swapping them again.

Should be, as long as all shares are set to COW, NOCOW disables data checksum capability, like explained in the link above.

There are read errors on disk1, you should be alerted for that (if notifications are enable), if you continue the rebuild disk will have corruption, cancel, replace cables on disk1 and try again.

No:

RAID controllers are not recommended, look for an LSI HBA instead. 3Gbps/6Gbps not much of a difference for spinners, but some 3Gbps controllers might be limited to 2.2TB.

FYI that was clearing, pre-clearing means clearing outside the array. Disk dropped offline, most likely a connection issue, but since there's no SMART more difficult to say, check connections and post new diags.

By default it creates a raid1 pool, if you use two different size devices pool will have the capacity of the smaller one, you can change the profile to a different one to use the full capacity (available options are in the linked FAQ entry), at the expense of redundancy.