On Mon, Aug 26, 2013 at 01:10:54PM -0600, Chris Murphy wrote: > > On Aug 26, 2013, at 11:41 AM, Nick Lee <em...@nickle.es> wrote: > > > There was a discussion on IRC a few days ago that the problem with the tree > > root's bloco was likely the result of either an issue with the disk itself, > > or the chunk tree/logical mappings. I ran the chunk recover, looked over > > the errors it found, and hit write. (If it failed, I was going to run > > something photorec, loss of organization as a side effect.) > > > > I can write something more clear after my flight lands tomorrow if you want.
> I'm just curious about when to use various techniques: -o recovery, > btrfsck, chunk-recover, zero log. 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. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Try everything once, except incest and folk-dancing. ---
signature.asc
Description: Digital signature
