Background: I had cable issues that have been resolved. Thinking I was in the clear, I ran a docker app, until I found the cache filled and mover did not move files as expected. Digging into the issue, I found a disk that I could not even 'manually move' (via unraid GUI) the files to.

Issue: Digging further I ran Check File System and found 3 disks with errors. I was considering the --repair option, but after reading the help section, which advises not to do so unless advised to do so, I stopped and came to the forums. Therefore, I'm requesting help.

Request: Should I rerun the Check File System with the --repair option or is there another path forward I should take? Attached is a recent diagnosis.

Edited July 5, 20251 yr by sniggil

I don't like using --repair with btrfs, since it can sometimes make things worse, first, I see data corruption being detected on disks 2 and 7

Jun 25 20:05:48 Marlin kernel: BTRFS info (device md2p1): bdev /dev/md2p1 errs: wr 0, rd 0, flush 0, corrupt 7515, gen 0

Jun 25 20:06:40 Marlin kernel: BTRFS info (device md7p1): bdev /dev/md7p1 errs: wr 0, rd 0, flush 0, corrupt 12, gen 0

Recommend first running memtest, and if noting is found, scrub those two disks and post the results from the GUI.

Also post the btrfs check output (without --repair) for the disks that it's finding issues with.

OK. Will do.

Memtest passed.

btrfs check output attached.

Thank you.

Edited July 5, 20251 yr by sniggil

And the scrub for the two disks detected any errors?

My apologies. All aborted. results attached

Edited July 5, 20251 yr by sniggil

Scrub aborting typically indicates a serious issue with the filesystem, I would recommend backing up and recreating all those filesystems, but with multiple disks having data corruption, there's almost certainly an underlying hardware issue, also note that memtest is only definitive if it finds errors, since you have multiple RAM sticks, it may be worth using the server with just one pair, and see if new corruptions come up after reformatting them, if yes, try with the other one, that will basically rule out bad RAM.

OK, thank you, I can remove memory to look for additional possible root causes, however as a point of information, I had cable issues (SATA power) that I believe was responsible for the underlying issue. A power adapter (4-pin molex to SATA power) was used because I could not order extra type 5 SATA power cables from Corsair. They are still out of stock many months later, but Corsair agreed to send me (2) type 5 SATA power connectors under warranty. The responsible cables (not suspect, but confirmed as I heard a drive's power drop while the case was open) have been replaced. I briefly mentioned this in the "Background" section, but didn't excessively elaborate on the issue as your time is very valuable and appreciated. My apologies if the lack of detail caused you to waste time. Again, I do not mind looking for additional possible causes to rule out likely suspects, but I also don't want to chase ghosts. Let me know, while I work on the backups and FS recreation for a bit.

51 minutes ago, sniggil said:

I had cable issues (SATA power) that I believe was responsible for the underlying issue.

That should not cause data corruption, unless maybe the files that ended up corrupt were being written at the time that there were issues with the power, and there's a firmware bug on the disks.