linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: Andrea Gelmini <andrea.gelmini@gmail.com>
Cc: Linux BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: help: btrfs bad tree block start
Date: Mon, 24 Jun 2013 12:28:48 -0400	[thread overview]
Message-ID: <20130624162848.GK4288@localhost.localdomain> (raw)
In-Reply-To: <CAK-xaQaP7-wvzd62GyydjJO2qeW3u9HGjE4Q9f013YpSmMV5vA@mail.gmail.com>

On Sun, Jun 23, 2013 at 05:33:59AM +0200, Andrea Gelmini wrote:
> Hi everybody,
>    and thanks a lot for your work.
> 
>    I have this problem.
>    With latest 3.9 kernel and btrfs-next I was close to full my home.
>    The system went read only mode while I was copying in some files.
> 
>    Everything was good. I can't write, but I can read and copy last files.
> 
>    Then I rebooted, but since that moment I cannot mount.
> 
>    The kernel complain is:
> 
> [ 1026.226883] device label 16K devid 1 transid 66906 /dev/mapper/glen-home
> [ 1026.227452] btrfs: disk space caching is enabled
> [ 1026.311650] Btrfs detected SSD devices, enabling SSD mode
> [ 1026.311825] btrfs bad tree block start 4262492213953725727 591596257280
> [ 1026.312000] btrfs bad tree block start 4262492213953725727 591596257280
> [ 1026.312010] btrfs: failed to read log tree
> [ 1026.332708] btrfs: open_ctree failed
> 
>    If I use btrfsck (Joseph one) I got this:
> 
> root@glen:/home/gelma/dev/prg/btrfs_josef# ./btrfsck --repair
> /dev/mapper/glen-home enabling repair mode
> Check tree block failed, want=591596257280, have=4262492213953725727
> Check tree block failed, want=591596257280, have=4262492213953725727
> Check tree block failed, want=591596257280, have=4262492213953725727
> Check tree block failed, want=591596257280, have=4262492213953725727
> Check tree block failed, want=591596257280, have=4262492213953725727
> read block failed check_tree_block
> Checking filesystem on /dev/mapper/glen-home
> UUID: 920ae0b9-55da-4606-af40-b58493c7882b
> checking extents
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> checking csums
> checking root refs
> found 127643191167 bytes used err is 0
> total csum bytes: 355191196
> total tree bytes: 2457419776
> total fs tree bytes: 1832763392
> total extent tree bytes: 195133440
> btree space waste bytes: 472140292
> file data blocks allocated: 1525241155584
>  referenced 396208013312
> Btrfs v0.20-rc1
> 
>    The home partition is 352,70 GiB.
> 
>    I've got backup, but I would like to recover it.
> 

So it looks like you just have a few transid mismatches but we manage to find
something that works out just fine.  Could you make an image of this fs for me
and upload it somewhere so I can pull it down and run some stuff on it?  I've
been toying with making fsck just re-write transid mismatched blocks if we
manage to put together the file system properly and I'd like to experiment with
this on your fs so maybe we can put it back together without you having to
restore from backups.  Thanks,

Josef

  parent reply	other threads:[~2013-06-24 16:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-23  3:33 help: btrfs bad tree block start Andrea Gelmini
2013-06-23  3:47 ` Andrea Gelmini
2013-06-24 16:28 ` Josef Bacik [this message]
2013-06-24 16:45   ` Andrea Gelmini
2013-06-24 17:53     ` Duncan

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=20130624162848.GK4288@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=andrea.gelmini@gmail.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).