linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: David Sterba <dsterba@suse.cz>
Cc: Josef Bacik <jbacik@fusionio.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: kernel BUG at fs/btrfs/volumes.c:3707 still not fixed in 3.7.1 (btrfs-zero-log required) but shown as "RIP btrfs_num_copies"
Date: Thu, 17 Jan 2013 06:16:43 -0800	[thread overview]
Message-ID: <20130117141643.GA14606@merlins.org> (raw)
In-Reply-To: <20130117113122.GW20089@twin.jikos.cz>

On Thu, Jan 17, 2013 at 12:31:22PM +0100, David Sterba wrote:
> On Sat, Jan 12, 2013 at 07:12:12PM -0800, Marc MERLIN wrote:
> > On Fri, Jan 11, 2013 at 09:49:52AM -0500, Josef Bacik wrote:
> > > Probably just related to whatever corruption it is you are seeing.
> >  
> > So I have no corruption afterall, correct?
> > 
> > That's good news, but then it does mean that unclean sudden shutdowns in the wrong place.
> > 
> > I still have a truncated fs_image if someone wants it, and with an
> > apparently uncorrupted FS, btrfs-image is still dying for me:
> > andalfthegreat:~# btrfs-image -c 9 /dev/mapper/cryptroot  /var/tmp/fs_image2
> > Check tree block failed, want=4261896192, have=10797364022063960087
> > Check tree block failed, want=4261896192, have=10797364022063960087
> > Check tree block failed, want=4261896192, have=13996544474027288730
> > Check tree block failed, want=4261896192, have=10797364022063960087
> > Check tree block failed, want=4261896192, have=10797364022063960087
> 
> want= are around 4G, have= numbers are way off, very likely a
> corruption. the number does not translate into a meaningful pattern.

Thanks for your answer, I appreciate it.

So this is the corruption that ends up in my log, and if I remove the log
that happened before the laptop died, then the rest of the filesystem seems
ok and scrub finds nothing wrong.

My very uneducatd guess is that when my SSD craps out, just before my laptop
locks up, it's either responsible for causing that corrupted log to be
written, or there is a bug in btrfs that happens where truncated writes
happen before a device comes of the sata bus.
Either way, I got this bug multiple times with the same device (which I just
replaced yesterday, just in case).

Here's what I've seen so far in case there is a useful pattern.
There is a mix of what I got from btrfs-zero-log and btrfs-image.
I did get the problem more often than just those, but those are the ones I
recorded before zero'ing the log.

Check tree block failed, want=259264512, have=12301165138967429629
Check tree block failed, want=259264512, have=12301165138967429629
Check tree block failed, want=259264512, have=7949122546735189447
Check tree block failed, want=259264512, have=12301165138967429629
Check tree block failed, want=259264512, have=12301165138967429629


Check tree block failed, want=4268204032, have=2075122916315869932
Check tree block failed, want=4268204032, have=2075122916315869932
Check tree block failed, want=4268204032, have=12746175583536274708
Check tree block failed, want=4268204032, have=2075122916315869932
Check tree block failed, want=4268204032, have=2075122916315869932

Check tree block failed, want=5212229632, have=12481778023482407252
Check tree block failed, want=5212229632, have=12481778023482407252
Check tree block failed, want=5212229632, have=14440972074482314957
Check tree block failed, want=5212229632, have=12481778023482407252
Check tree block failed, want=5212229632, have=12481778023482407252

Check tree block failed, want=73949184, have=14419929907352990360
Check tree block failed, want=73949184, have=14419929907352990360
Check tree block failed, want=73949184, have=12288424950725929455
Check tree block failed, want=73949184, have=14419929907352990360
Check tree block failed, want=73949184, have=14419929907352990360

Check tree block failed, want=4261896192, have=10797364022063960087
Check tree block failed, want=4261896192, have=10797364022063960087
Check tree block failed, want=4261896192, have=13996544474027288730
Check tree block failed, want=4261896192, have=10797364022063960087
Check tree block failed, want=4261896192, have=10797364022063960087

I'm hopeful this is useful somehow, and hopefully btrfs will stop oops'ing
at boot time, requiring a recovery disk and specialized knowledge to
recover, when this happens.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

      reply	other threads:[~2013-01-17 14:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08 16:49 kernel BUG at fs/btrfs/volumes.c:3707 still not fixed in 3.7.1 (btrfs-zero-log required) but shown as "RIP btrfs_num_copies" Marc MERLIN
2013-01-08 17:10 ` Hugo Mills
2013-01-08 18:09   ` Marc MERLIN
2013-01-14  6:28   ` Marc MERLIN
2013-01-08 18:25 ` Josef Bacik
2013-01-08 18:46   ` Marc MERLIN
2013-01-10 16:20     ` Marc MERLIN
2013-01-11 14:49       ` Josef Bacik
2013-01-13  3:12         ` Marc MERLIN
2013-01-17 11:31           ` David Sterba
2013-01-17 14:16             ` Marc MERLIN [this message]

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=20130117141643.GA14606@merlins.org \
    --to=marc@merlins.org \
    --cc=dsterba@suse.cz \
    --cc=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).