after crash, btrfs attempts to clean up extent it has already cleaned up
diff mbox

Message ID orsi0kt4um.fsf@livre.home
State New
Headers show

Commit Message

Alexandre Oliva Feb. 23, 2016, 4:42 a.m. UTC
Are there others getting errors like $SUBJECT, described in more detail

If my theory is correct, workloads involving lots of snapshots, such as
Ceph OSDs, might run into it quite often.

Although I could recover from a few such metadata corruptions by hand,
when btrfs check --repair couldn't fix it, it's quite cumbersome.  I
wonder if a change like this, made conditional on a mount option, would
be considered appropriate.  I considered making it conditional on -o
recovery, but ended up just making it unconditional for my own temporary

As for fixing metadata corruption by hand, I've been thinking it might
be useful to have some tool to help navigate and change metadata,
extract files and whatnot, much like debugfs for ext* filesystems.
Would others find it useful?  Is anyone else already working on such a

diff mbox

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index cadacf6..849765a 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -6356,7 +6356,7 @@  static int __btrfs_free_extent(struct btrfs_trans_handle *trans,
 			"unable to find ref byte nr %llu parent %llu root %llu  owner %llu offset %llu",
 			bytenr, parent, root_objectid, owner_objectid,
-		btrfs_abort_transaction(trans, extent_root, ret);
+		ret = 0; /*btrfs_abort_transaction(trans, extent_root, ret);*/
 		goto out;
 	} else {
 		btrfs_abort_transaction(trans, extent_root, ret);