All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: Marc MERLIN <marc@merlins.org>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: kernel 3.8.8: btrfs still crashes on boot when it can't replay a log
Date: Fri, 17 May 2013 12:54:56 -0400	[thread overview]
Message-ID: <20130517165456.GH1765@localhost.localdomain> (raw)
In-Reply-To: <20130516150918.GB26762@merlins.org>

On Thu, May 16, 2013 at 09:09:18AM -0600, Marc MERLIN wrote:
> I've reported this bug a few times over different kernel versions over the
> last year now, and unfortunately it's still not fixed as of 3.8 (yes, I know
> 3.9 is out, I'm just about to switch).
> 
> What happens as far as I know:
> I have btrfs on top of dmcrypt on an SDD.
> 
> The SSD on occasion seems to just hang, so I have to power cycle my laptop.
> I can't say how much the SSD did and did not write before stopping to work.
> 
> Then, maybe one time out of 2 or 3, btrfs crashes when I reboot and it tries 
> to replay the log.
> 
> I'm then forced to do this from emergency boot media:
> 
> gandalfthegreat:~# btrfs-zero-log /dev/mapper/root                                                        
> Check tree block failed, want=64855564288, have=14954667565421255623                                      
> Check tree block failed, want=64855564288, have=14954667565421255623                                      
> Check tree block failed, want=64855564288, have=7474503720151340134                                       
> Check tree block failed, want=64855564288, have=14954667565421255623                                      
> Check tree block failed, want=64855564288, have=14954667565421255623                                      
> read block failed check_tree_block   
> 
> The last bits of the crash before I zero the log:
> http://marc.merlins.org/tmp/btrfs-3.8.8.jpg
> 
> Still issues with btrfs_numb_copies.
> 
> This has been going on for over a year now, not very pleasant :)
> 
> Is there no way you can corrupt logs in a test lab and reproduce this?
> 
> Or is it still known to happen due to missing code that decides whether a log is corrupt 
> and whether to discard it before the code reads it and crashes?
> 
> If so, could you add this to the list of things to fix to make btrfs a bit
> less scary to others? :)
> (and of course more production ready, this repeated problem would kill any
> server it happens on)
> 

This has been all fixed in 3.10.  Thanks,

Josef

  parent reply	other threads:[~2013-05-17 16:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16 15:09 kernel 3.8.8: btrfs still crashes on boot when it can't replay a log Marc MERLIN
2013-05-17 15:48 ` Marc MERLIN
2013-05-17 16:54 ` Josef Bacik [this message]
2013-05-18  1:25   ` Marc MERLIN
2013-05-18  1:51     ` Josef Bacik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130517165456.GH1765@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marc@merlins.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.