JorgeB

Correct, you do this: https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself The final option, assuming actual disk has a clean filesystem without a lost+fond folder, and it should have, you do a new config and instead of rebuilding disk3 based on the emulated disk you re-sync parity based on the actual disk.

May 5 10:26:53 LuNAS kernel: ? Sys_DumpTask+0xe9/0xf1 [corefreqk] May 5 10:26:53 LuNAS kernel: Cycle_AMD_Family_17h+0x31b/0xb37 [corefreqk] Unisntall the corefreq plugin.

Yes, that's expected, you need to rebuild the disk to fix that, but first check the lost+found folder, if there are lots of files there and/or the emulated disk is missing some data you should not rebuild on top of the old disk, you have more than one option: -rebuild to a new disk if available, then you can compare the data with the old disk -compare the old disk with the emulated disk now, you can do that by first stopping the array, unassign disk3, start the array, Unraid will continue to emulate the disk, use the UD plugin to mount the old disk and compare the data with the emulated one, just note that before mounting the disk with UD you need to change the XFS UUID since it will be the same as the emulated disk, you can to that in the UD settings -final option is instead of rebuilding the disk doing a new config (Tools -> New config) to reset the array and re-sync parity based on the actual disk3, which should not have the lost+found folder but you should confirm before doing it, using the same procedure to mount it with UD as described above.

Yep.

This usually means memory problems or some other kernel memory corruption, start by running memtest, the filesystem should be OK after that's fixed, since it went read-only to prevent corruption, though if it's bad RAM there could be some data corruption, etc.

Stop the array, then start in maintenance mode and run the command, after that's done start the array and disk3 should now mount, but because of the filesystem corruption there can be some data loss, so look for a lost+found folder and see if there are any lost files there, if all looks OK you can rebuild on top, if it doesn't you can instead try to access the data on the actual disk.

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Sorry for replying in english, this caught my eye while browsing. You always need to specify the partition to check a filesystem, i.e.: xfs_repair -v /dev/sdf1 Also note that the above will check the actual disk, not the emulated disk which is what you currently have, to check and repair the filesystem in the emulated disk (or any other assigned array disk and keep parity valid) you need to start the array in maintenance mode and use: xfs_repair -v /dev/md3 Where the 3 is the disk number, if it asks for -L use it, more info in the check filesystem wiki page.

Looks clean so far. Something is writing to disk4

Unless you have checksums for the existing files, or were using btrfs, there's no way to known if the problem is with parity or data, we can only try to find the current issue and put parity back in sync.

See if it get faster if you set it to performance, or slower if set to powersave. Parity sync is single threaded, and with a parity2 it uses more CPU, still with just 8 disks I would think it should be faster than that with that CPU.

You can download the stable zip then just replace all the bz* files on the flash drive and reboot.

Constant errors with the HBA, post new diags after rebooting since can't see the boot sequence on the previous logs.

Still issues with disk1, also swap/replace power cable.

Run memtest, if no errors are found after a couple of passes run a correcting check followed by a non correcting one, if there are errors on the 2nd run post new diags without rebooting.

Appdata is set to cache="yes", so every time the mover runs it moves files to the array, set to cache=prefer, stop docker service and move everything to cache.

Problem with the onboard SATA controller, quite common with some Ryzen boards: May 4 16:02:11 YoungHomeTower kernel: ahci 0000:01:00.1: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000f address=0x78080000 flags=0x0000] BIOS update might help, or use an add-on controller.

Shouldn't be needed but you can do it. All. If you can't identify the files or don't think you need them you can delete the folder.

If all looks good you can rebuild on top: https://wiki.unraid.net/Manual/Storage_Management#Rebuilding_a_drive_onto_itself

Correct, make sure the emulated disk is mounting and contents look correct, whatever is there is what's going to be rebuilt, also good idea to check SMART since we couldn't before.

Although I expect old disk5 contents to be OK best to check before doing the new config, so mount the disk with UD and check, if you want to do it with the array started you need to change the XFS UUID first, option for that is in the UD plugin settings. It won't mess anything up but it won't fix it, i.e., current lost+found folder will remain as is on that disk.

Yes, mount the old disk with UD, you'd need to change the XFS UUID but that can be done in UD, then use for example rsync to compare/sync contents. No, you just go to Tools -> New config -> Preserve all assignments, then re-assign disk5, start array to re-sync parity based on the actual disk5 contents, which should not have the filesystem corruption found on the emulated disk, but you can also check that with UD before doing it.

Not much you can do about disk4, corruption could have been caused by parity not being 100% in sync or errors on another disk(s) during the rebuild, CRC errors shouldn't be an issue, except for a small performance impact. As for disk5 I would recommend either rebuilding to a new spare disk and then comparing the data with old one or doing a new config and re-syncing parity instead.

Yes.