All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Robert Munteanu <robert.munteanu@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Vytautas D <vytdau@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Date: Mon, 3 Aug 2015 09:22:22 +0800	[thread overview]
Message-ID: <55BEC24E.5010908@cn.fujitsu.com> (raw)
In-Reply-To: <CAC8ULPbe+E6JzGS-BYvjoLTN+Y9j6PYGC4U3f5cYhgz=eaaUOg@mail.gmail.com>

Yes, you're right, that's a dead loop.

But for better debugging, would you please upload the following info?
1) output of command "btrfs-debug-tree -t 5 <DEV>".
The only important things are info about that inode.
Whose objectid(first item in a key) is 14214570 and type is one of the 
following:
INODE_ITEM, INODE_REF, EXTENT_DATA
So you may only need to cut the things like below:
======
         item 4 key (14214570 INODE_ITEM 0) itemoff 15881 itemsize 160
                 inode generation 6 transid 6 size 1073741824 nbytes 
1073741824
                 block group 0 mode 100644 links 1 uid 0 gid 0
                 rdev 0 flags 0x0
         item 5 key (14214570 INODE_REF XXX) itemoff 15866 itemsize 15
                 inode ref index 2 namelen 5 name: file1
         item 6 key (14214570 EXTENT_DATA 0) itemoff 15813 itemsize 53
                 extent data disk byte 2176843776 nr 134217728
                 extent data offset 0 nr 134217728 ram 134217728
                 extent compression 0
         item 7 key (14214570 EXTENT_DATA XXX) itemoff 15760 itemsize 53
                 extent data disk byte 2311061504 nr 134217728
                 extent data offset 0 nr 134217728 ram 134217728
                 extent compression 0
         ....(All items with 14214570 objectid is needed to debug)
======

And it's highly recommended to only cut that part and paste it.
Not only to reduce the output, but also help your privacy.
As you can see, INODE_REF contains file name, which can be sometimes 
leaking your personal infomation.

2) output of command "btrfs-debug-tree -t 2 <DEV>"
Just in case your extent tree mismatch with fs tree.

If you don't like to execute 2 commands and are OK with leaking file/dir 
names, you can also use "btrfs-debug-tree <DEV>" to dump every metadata 
info.

Alternatively, if "btrfs-image -c9 <DEV>" works without problem, it will 
also helps a lot for debugging.

Thanks,
Qu


Robert Munteanu wrote on 2015/07/31 16:38 +0300:
> On Fri, Jul 31, 2015 at 5:08 AM, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote:
>> Any full output about it?
>
> Please see the attached log. I left the process running for about 4
> hours, and after the first five minutes all it cared about was a
> single inode. I ended up stopping it as it looks like it's not making
> progress.
>
>> Not sure if it real loops, but maybe the inode number changed in later
>> output?
>
> Looks to me like it's the same inode
>
>    $ awk '/ for inode/ { print $7  } ' screenlog.0  | sort | uniq
>    14214570
>
> Thanks,
>
> Robert
>
>
>
>
>
>
>

  parent reply	other threads:[~2015-08-03  1:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-12 12:19 btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 Robert Munteanu
2015-06-17 17:46 ` Marc MERLIN
2015-06-17 19:41   ` Marc Joliet
2015-06-18 11:05   ` Robert Munteanu
2015-06-25  4:16     ` Marc MERLIN
2015-06-25 12:08       ` Vytautas D
     [not found]         ` <CABE5tBasBsycy_+q=RZj1dpqsLTREJTA72F-ZwNLt=kLX6wXhg@mail.gmail.com>
2015-06-25 21:09           ` Marc MERLIN
2015-06-17 18:48 ` Jeff Mahoney
2015-06-18 11:08   ` Robert Munteanu
2015-06-26  1:54 ` Qu Wenruo
2015-06-26  2:08   ` Qu Wenruo
2015-07-09  3:09     ` Chris Murphy
2015-07-09 10:52       ` Vytautas D
     [not found]       ` <CAO5K3OcA1_Z4-jvv_2C0StBkOr++_vUX4kOspY8cuhnX2t3z_A@mail.gmail.com>
2015-07-09 21:38         ` Chris Murphy
2015-07-10  0:34           ` Qu Wenruo
2015-07-10  0:45             ` Chris Murphy
2015-07-10  4:45               ` Qu Wenruo
2015-07-14 23:29                 ` Chris Murphy
2015-07-26 21:47             ` Robert Munteanu
2015-07-30 13:16               ` Robert Munteanu
2015-07-31  2:08                 ` Qu Wenruo
2015-07-31 13:38                   ` Robert Munteanu
2015-08-03  0:54                     ` Qu Wenruo
2015-08-03  1:22                     ` Qu Wenruo [this message]
2015-08-03  7:45                       ` Robert Munteanu

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=55BEC24E.5010908@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=robert.munteanu@gmail.com \
    --cc=vytdau@gmail.com \
    /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.