On Tue, Aug 21, 2012 at 09:50:58AM -0700, Not Zippy wrote:
> Thanks for the analysis, unfortunately I get the same assert error
> when I attempt to run the repair from the compiled source.
> 
> # ./work/builds/btrfs-progs/btrfsck
> usage: btrfsck dev
> Btrfs Btrfs v0.19

'git describe' would be more helpful, but as the following command
succeded, I assume that you're on the right version.

> # ./work/builds/btrfs-progs/btrfsck --repair /dev/sda2
> enabling repair mode
> checking extents
> leaf parent key incorrect 46329503744
> bad block 46329503744
> owner ref check failed [46329503744 4096]
> repair deleting extent record: key 46329503744 168 4096
> adding new tree backref on start 46329503744 len 4096 parent 256 root 256
> repaired damaged extent references

so it's able to fix that error, but due to failure in the next phase the
change is not permanent -- a quick hack here would be to commit
immediatelly after this phase

--- a/btrfsck.c
+++ b/btrfsck.c
@@ -3572,6 +3572,8 @@ int main(int ac, char **av)
        if (ret)
                fprintf(stderr, "Errors found in extent allocation tree\n");

+       goto out;
+
        fprintf(stderr, "checking fs roots\n");
        ret = check_fs_roots(root, &root_cache);
        if (ret)
---

> checking fs roots
> btrfsck: btrfsck.c:397: process_inode_item: Assertion `!(rec->ino !=
> key->objectid || rec->refs > 1)' failed.
> Aborted

This would need more information to analyze further, like full output of
btrfs-debug-tree, and capture actual values from the Assertion to match
them against the output. Additionally, I'm still interested in details
about conditions that lead to this corruption, it's less painful to
reproduce it locally than the remote debugging ping-pong (though
sometimes nothing else is available).
I think it'd be interesting to dig deeper, but you were able to get to
your data so it's not probably that urgent for both of us.


david
--
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

Reply via email to