JorgeB

Complete diagnostics would be better, but errors on 2 disks at the same time are usually not a disk problem, though both disks show a high number of recovered sectors, run a long SMART test on both.

No, you could only add if current cache was btrfs, since the cache disk appears to be in very bad shape best bet it's to use ddrescue, but note that there will likely still be corrupt files.

There are read errors on disk5, and that makes it impossible to correctly emulate disk3 (assuming parity is valid, and I'm not sure it is since I didn't follow all you did before), replace cables on disk5 and post new diags.

It's a strange situation, since there's no apparent filesystem corruption if the space is used the data should be there, and if it's not it should not be taking any space either.

On the main page click on Shares, then appdata, there you can select the "use cache" option, good idea to turn the help on so you understand the different behavior of each option, it should already be set to cache=prefer which is what you want. After checking that you can run the mover, first disable the docker service (settings -> docker), all dockers will be stopped, then run the mover, that's on the main page below the start/stop array buttons, after it's done check that appdata only exists on cache now, you can also check that on the shares page by clicking on "compute" size on the appdate share (note that any existing files with the same name on cache would prevent the others being moved).

You can't move from a user share to a disk share, that can result in data loss, you can use the mover after setting the correct cache mode (prefer in this case) or move from disk share to disk share, e.g. /mnt/disk1/appdata to /mnt/cache/appdata

It isn't there are various reports of sync errors during a parity check when running out of spec RAM with Ryzen despite no memtest errors.

Recommended doing the same for appdata, but note that as of last diags there were some files on disk1 and cache, so you need to move them first.

Couple of months ago there was a reallocated sector on that disk, you should a long SMART test.

Can't see how, but if there are writes to parity2 there should be the same ones to parity, though you can't look at the the number of writes stats to compare, since they can vary wildly from device to device, even when doing the same activity, when can look at the speeds stats, those are reliable.

You also have corrupt data on the array, and that's not surprising since if data is getting corrupt on cache most likely it's getting corrupt on the array as well, you need to delete/restore those files, and find out what is causing the corruption, it's some hardware problem. Syslog after a scrub will show the corrupt files, e.g.: (path: Videos/TV Shows/Comedy/Cheers (1982)/Season 7/Cheers (1982) - S07E10 - Bar Wars II- The Woodman Strikes Back.avi)

Everything looks normal for now, you might want to look at this for better cache pool monitoring.

You can use the Unassigned Devices plugin if the drive is formatted with one of the supported filesystems.

No, I missed this part. If the data is actually missing it's probably the best bet.

That looks more like a power/connection issue, swap/replace cables and try again.

Cache filesystem is corrupt, see here for some recovery options. Also see here since you're running the RAM above the officially supported speed, and that's known to cause stability issues with Ryzen, including data corruption.

Yes.

There are issues.

Please post the diagnostics: Tools -> Diagnostics

Very unlikely that would happen, most likely explanation is that parity wasn't already valid, run another check now (non correcting), if there are more sync errors you likely have a hardware problem.

It's tied to the default warning thresholds set on Settings -> Disk Settings

No devices are being detected on the Marvell controller: May 31 14:29:33 Tower kernel: ata8: SATA link down (SStatus 0 SControl 300) ... May 31 14:29:33 Tower kernel: ata9: SATA link down (SStatus 0 SControl 300) ... May 31 14:29:33 Tower kernel: ata10: SATA link down (SStatus 0 SControl 300) ... May 31 14:29:33 Tower kernel: ata7: SATA link down (SStatus 0 SControl 300)

No, you can just do the new config now.

Disk looks healthy but if you already replaced cables there could still be a problem there, make sure you also replaced/swapped the power cable, I would also swap to a different SATA port and try again if the issues continue it's likely the disk.

You just need to register your nick.