On Aug 26, 2013, at 1:31 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > > Let's assume that you don't have a physical device failure (which > is a different set of tools -- mount -odegraded, btrfs dev del > missing). > > First thing to do is to take a btrfs-image -c9 -t4 of the > filesystem, and keep a copy of the output to show josef. :) > > Then start with -orecovery and -oro,recovery for pretty much > anything. > > If those fail, then look in dmesg for errors relating to the log > tree -- if that's corrupt and can't be read (or causes a crash), use > btrfs-zero-log. > > If there's problems with the chunk tree -- the only one I've seen > recently was reporting something like "can't map address" -- then > chunk-recover may be of use. > > After that, btrfsck is probably the next thing to try. If options > -s1, -s2, -s3 have any success, then btrfs-select-super will help by > replacing the superblock with one that works. If that's not going to > be useful, fall back to btrfsck --repair. > > Finally, btrfsck --repair --init-extent-tree may be necessary if > there's a damaged extent tree. Finally, if you've got corruption in > the checksums, there's --init-csum-tree. This is helpful. Thanks. Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
