I am currently running Unraid 7.2.0; Intel core i5-12400; 32GB RAM; 2 parity drives, 9 data drives; mirrored cache drive.

I saw errors in dmesg that one of my disks was having issues, and needed to have xfs_repair run.

I stopped the array, and then started it in maintenance mode.

I went to my disk3, checked the filesystem, which completed successfully but indicated a large number of errors. I then clicked to fix the errors. However, it ends with:

...
junking entry "PixelStreamingVCam" in directory inode 4882238570
corrected i8 count in directory 4882238570, was 4, now 3
entry "Materials" in shortform directory 4882238587 references non-existent inode 6474655066
junking entry "Materials" in directory inode 4882238587
corrected i8 count in directory 4882238587, was 5, now 4

fatal error -- adding rmap to in-memory btree, err 117

I've tried replacing the disk and allowing the array to rebuild, but the filesystem errors are in the parity drives, after the rebuilds, the new drive is in the same state as the old drive. I've tried running xfs_repair manually with various options such as -m 8192 which fails the same way.

After I initially stopped the array to try to run xfs_repair, every time I've started the array, disk 3 is missing (Unmountable: wrong or no file system) and not emulated. Even if I remove the drive from the array, the data is not emulated. The drive currently in my server is a replacement drive, not the original. I can tell from the logs that most of the entries that are failing are backups of my development environment, but I know that there were other random things missing as well such as pictures and videos, the thumbnails in my gallery are messed up. I'm not sure how to proceed in recovering as much data as I can from disk3. Generally, finding information related to the error message has been difficult. Nothing on the Unraid forums, and only one result on the forums of level1techs.com which is marked solved, but without any solution as far as I can tell. As far as I can see, there are no other references to "adding rmap to in-memory btree" anywhere.

30 minutes ago, AnthonyZ71 said:

the new drive is in the same state as the old drive.

This is normal; parity can't help with filesystem issues.

My first recommendation would be to update to 7.3.0 since it includes newer xfs-progs, then try running xfs_repair again. If it still fails, post the diagnostics.

Same error after the upgrade. Confirmed that xfs_repair is newer... The old one was 6.x, the new one is 7.0.0.

I've attached the diagnostics.

highbrow-diagnostics-20260514-1318.zip

May 14 13:17:19 Highbrow kernel: BTRFS info (device nvme1n1p1): bdev /dev/nvme1n1p1 errs: wr 0, rd 0, flush 0, corrupt 862, gen 0

May 14 13:17:19 Highbrow kernel: BTRFS info (device nvme1n1p1): bdev /dev/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 850, gen 0

Btrfs is detecting a lot of data corruption. This is typically bad RAM, and could be related to xfs_repair failing, if the RAM really is failing, recommend running memtest first.

Thankfully given current RAM prices, the memtest passed. I let it run through two complete passes before bringing the server back up.

Reset the pool stats and scrub the pool, then post the scrub results if there are any new errors.

UUID:             b4f60f56-fbce-4d97-8690-7f4021244be5
Scrub started:    Fri May 15 08:32:56 2026
Status:           finished
Duration:         0:01:25
Total to scrub:   518.91GiB
Rate:             6.11GiB/s
Error summary:    csum=2
  Corrected:      0
  Uncorrectable:  2
  Unverified:     0

But at some point, something has changed some settings somewhere, I've been upgrading Unraid for a very long time, so I'm not sure when my settings might have been changed. Disk9 is a tiny 2.5" SSD that I only use for storing the syslog. But several of the shares no longer have that disk disabled for usage.

I have the mover disabled because I don't use the cache drives as a cache for the array. I found too many problems when the cache drives fill up; things start breaking. So I disabled "real" caching a long time ago. The cache drive is actually used only for three things:

• The appdata for docker images

• Any volume mounts for docker images

• The system directory for docker (docker and libvirt)

But I'm seeing other files on the cache at the moment, so I need to investigate that. Fix Common Problems indicates the same:

Share media set to not use the cache, but files / folders exist on the cache drive

I assume the right path forward here is to stop the docker subsystem, move everything from the cache drives to the array, reformat the cache drives, move the files back to the cache, and then restart the docker subsystem?

Finally, I see the forum post from Thamian Solus with the exact same error message that landed me here. I had this problem before upgrading to 7.3.0, so that's not the root cause of the problem. I assume xfs errors slowly built up over time for whatever reason until it reached a point where xfs_repair can't repair the disk.

I have to wonder are we going to start seeing a LOT of xfs_repair issues with this same error message. I'm not sure what's going on with xfs file system, I thought it was one of the more stable linux filesystems right up there with ext4.

1 hour ago, AnthonyZ71 said:

Uncorrectable:  2

Look in the syslog and there should be one or more files listed during the scrub that are corrupt. Those files should be deleted/restored from a backup , then run another scrub to confirm 0 errors.

Since memtest didn't detect any issues, they may be old errors, but note that memtest is only definitive if it finds errors, so keep monitoring the mpool. If new corruptions are detected, there's still a problem.

The xfs issue could or could not be related to the issues that caused the data corruption on btrfs, but if xfs_repair can't fix it and you don't have a backup, best bet is to use a file recovery app like UFS Explorer to recover the data and then reformat the disk.

Luckily, the errors are with the system/docker/docker-xfs.img, so no data loss at all. Just need to stop docker, delete the file, restart docker, and let the images all redownload.