Are there others getting errors like $SUBJECT, described in more detail at https://bugzilla.kernel.org/show_bug.cgi?id=112561
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 use. 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 thing? 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, owner_offset); - 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); -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html