Re: Hitting error after failed balance

[Duncan <1i5t5.duncan@cox.net>]

Mitchel Humpherys posted on Tue, 14 Jan 2014 15:21:19 -0800 as excerpted:

> On Tue, Jan 14 2014 at 11:47:18 AM, Mitchel Humpherys
> <mitch.special@gmail.com> wrote:

>>     
>>     Btrfs v3.12
>>
>>     $ uname -a
>>     Linux mitchelh-linux 3.12.6-1-ARCH #1 SMP PREEMPT Fri
>>     Dec 20 19:39:00 CET 2013 x86_64 GNU/Linux
>>
> Well I tried btrfsck --repair and now it appears to be unmountable...

[If you wish to continue being direct-mailed as well, please keep that 
request in every reply, as I read/reply-to this list as a newsgroup via 
gmane.org, and in my news client replying via email is an extra step, so 
I don't do it by default but do try to honor requests when I see 'em.]

You're aware that btrfsck --repair is considered a last-ditch option, 
right?

In some cases it makes the problems worse, not better.  There are other 
things to be tried first, and when it comes down to btrfsck --repair, if 
the filesystem is mountable as yours was, the recommendation is to update 
your backups if you need to (since btrfs is considered testing and still 
under development, you should have routine/tested backups any time you're 
testing it anyway, thus it's update an existing backup, not make your 
FIRST one =:^), test that you can recover from the backup in case the 
btrfsck --repair makes things worse, and /then/ try the repair.

>     $ sudo mount -a
>     mount: wrong fs type, bad option, bad superblock on
>     /dev/sda6, missing codepage or helper program, or other error

> and here's the kernel log from the mount -a:
> 
>     [13479.995191] btrfs: failed to read log tree
>     [13480.051334]
>     btrfs: open_ctree failed

There's the btrfs-zero-log tool.  When it's saying the log can't be read, 
that's the thing to try.  You will lose the last few seconds of 
transactions from the log since the last commit, but btrfs is designed to 
maintain a consistent commit-state, so in theory, anyway, when the log is 
corrupt and can't be used anyway, zeroing it should at least get you back 
to a consistent filesystem state.

Tho I'm not sure what further damage btrfsck --repair might have done or 
what further damage you may have had from the failed balance and 
previous.  But hopefully without the log, the filesystem is at least 
mountable.

> So close! :)
> 
> Am I completely hosed?

If zero-log doesn't work, there's still hope.  You can try btrfs-find-
root and btrfs restore, using the instructions here:

https://btrfs.wiki.kernel.org/index.php/Restore

In general, if you haven't already, I'd suggest spending some time 
reading the documentation on the wiki.  You can also read some of the 
back-list posts right here, say from gmane.org, since not all the common 
wisdom on the list may be on the wiki just yet.  I use the nntp/news 
interface, but there's also a web interface (actually multiple web 
interfaces, take your pick =:^), if you're not familiar with nntp or 
simply don't want to bother setting up a proper nntp client.

If that doesn't work either, well, it may be time to mkfs.btrfs and fall 
back to the backups.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman