JorgeB

Every rebuilt disk will have the same filesystem as the disk it's replacing, it can only be like that, the default fs is for added drives.

Start here.

Are both detected on the system devices? Also, please post the diagnostics: Tools -> Diagnostics

It's a known issue and it should be corrected on the next release.

Docker image is corrupt, delete and re-create, see docker FAQ if needed, cache filesystem seems OK for what I can see.

Scrub can't help in this case, see the FAQ, btrfs restore is the most likely to work for this.

Filesystem is corrupt, you can try btrfs restore on the same FAQ entry.

Yes, but only shares set to cache="yes" will be moved.

9207 is plug'n play, devices are tracked by serial number, not where they are connected, just don't use RAID controllers.

Unraid doesn't stripe data, it writes to a single disk (plus parity) so max write speed is the speed of the slowest disk involved (using turbo write).

Same users have issues getting a DHCP address with latest release, try setting a static address.

Just for future reference, the cache problem was because you went from 4 devices to 1, you can only remove one device at a time from a redundant pool, and after that you re-assigned the old devices but without "forgetting" the existing pool, so they were erased.

Note that the total read speed is this high because you have turbo write and it reads all disks when there are array writes, you just need to find who/what is doing that, what @jonathanmsuggested is the first thing to try, you can also boot with GUI mode to still have the GUI after disconnecting the server form the LAN.

Same users have issues getting a DHCP address with latest release, try setting a static address.

The problem is that it doesn't affect everyone, I have a pool of MX500 for more than a year working without any issues.

Docker image was re-create twice, try rebooting and post new diags if it still doesn't start.

Start the array in maintenance mode and run reiserfsck --rebuild-tree on that disk.

Beta should be perfectly safe, it's the same as v6.8.3 just with a newer kernel.

No, parity can't fix filesystem corruption, if you were in the middle of a --rebuild-tree you need to run it again.

Just recently you could get form LT's cloud, not anymore, I guess they recently deleted older releases, why did you want it, v6.7.x has known performance issues.

Replace the bz* files on the flashdrive with the ones from the zip and reboot.

Something is going on there, that array activity is not normal, what if you boot in safe mode? (still leaving all VMs/dockers disable)

Enable mover logging (settings -> scheduler) then run the mover and post the diagnostics: Tools -> Diagnostics, also mention the share name your trying to move.

Test should be run with a single stream.

If you get the same 40MB/s writing to the array with or without turbo write, and to an SSD cache pool, the problem is likely lan related, or on the source computer. Also, regarding the original question, the disks on the omboard SATA ports are correctly linking at 3Gbps, the Seagate on the LSI is also linking at 3Gbps, only the WDs are linking at 1.5Gbps, so it's a controller or device issue/compatibility, make sure the LSI is running the latest firmware, but note that for those disks it won't make much difference since their max read/write speed is around 140/150MB/s.