Created attachment 242101 [details]
I know this is irrelevant, but here’s what happend when I try to delete some files which are corrupt

Here’s my problem :

I ran duperemove and it process got caught in an initerruptible state forcing me to perform an unclean shutdown (I couldn’t shutdown the computer without umounting the btrfs filesystem since it was in use by duperemove).
Since then, the filesystem is damaged in a way which makes I can remove some large files (It produce a kernel backtrace in the log).



I expected btrfs check --repair --init-extent-tree -b /dev/dm-7 could return my filesystem in a state that would allow me to delete it’s largest files.

Unfortunately, It seems to always get caught in an infinite loop (full cpu with no disk access) after printing this :
Checking filesystem on /dev/dm-7
UUID: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
Creating a new extent tree
Failed to find [75191291904, 168, 4096]
btrfs unable to find ref byte nr 75191291904 parent 0 root 1  owner 1 offset 0
Failed to find [75191316480, 168, 4096]
btrfs unable to find ref byte nr 75191316480 parent 0 root 1  owner 0 offset 1
parent transid verify failed on 75191349248 wanted 3555361 found 3555362
Ignoring transid failure
checking extents [O]

Before, the unclean shutdown, btrfs check was taking less than a minute (it contains ~240Gb of data in 51Gb and about 150000 files) (there’s no snapshots or subvolumes).

After investigating a bit in gdb, I identified the piece of code where the problem lies :
		while (1) {
			ret = run_next_block(root, bits, bits_nr, &last,
					     pending, seen, reada, nodes,
					     extent_cache, chunk_cache,
					     dev_cache, block_group_cache,
					     dev_extent_cache, rec);
			if (ret != 0)
				break;
		}
Because ret never become true, the loop is infinite at some point in the checking.


I’m not an export in filesystems so I couldn’t invastigate further, but the issue is still reproductible, and I still can’t delete some of my largest files.
I can post additionnal informations if necessary.