From: Marc MERLIN <marc@merlins.org>
To: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Cc: Liu Bo <bo.li.liu@oracle.com>, linux-btrfs@vger.kernel.org
Subject: Re: 3.15.1: kernel BUG at fs/btrfs/locking.c:269
Date: Fri, 4 Jul 2014 07:02:11 -0700 [thread overview]
Message-ID: <20140704140211.GG26932@merlins.org> (raw)
In-Reply-To: <1404467946-4429-1-git-send-email-wangsl.fnst@cn.fujitsu.com> <53B645D4.1060003@cn.fujitsu.com>
On Fri, Jul 04, 2014 at 02:12:36PM +0800, Wang Shilong wrote:
> OK, i found there is a mirror num recorded in struct
> @extent_buffer, so it is not diffcult
> to locate the real physical address that this corrupt metadata block
> locates.
>
> But another question is that if such problems happen, it should also
> help little, because
> usually other mirrors maybe have the same errors...
I understand, although at least knowing which filesystem has the
problem, whether it got auto corrected, or not, is good.
Imagine if I get 500 of those errors in syslog. Even if btrfs can auto
correct them, as an admin, I would want to know this because it means
something likely bad happened and I may want to inspect that filesystem
for damage, or the hardware for faults.
So the extra output is very useful, thank you.
> Anyway, let me see if there are any other output even dose not
> output btrfs specific info.
Thank you very much.
On Fri, Jul 04, 2014 at 05:59:06PM +0800, Wang Shilong wrote:
> Marc argued that if there are several btrfs filesystems mounted,
> while users even don't know which filesystem hit the corrupted
> errors something like generation verification failure.
>
> Since @extent_buffer structure has a member @fs_info, let's output
> btrfs device info.
I don't know the btrfs code much, but looking at the patch, it looks
good, thank you for that.
Marc
> Reported-by: Marc MERLIN <marc@merlins.org>
> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
> ---
> Tell me if missed anything here...
> ---
> fs/btrfs/disk-io.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index 08e65e9..bd52ca0 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -351,9 +351,9 @@ static int verify_parent_transid(struct extent_io_tree *io_tree,
> ret = 0;
> goto out;
> }
> - printk_ratelimited("parent transid verify failed on %llu wanted %llu "
> - "found %llu\n",
> - eb->start, parent_transid, btrfs_header_generation(eb));
> + printk_ratelimited("BTRFS (device %s): parent transid verify failed on %llu wanted %llu found %llu\n",
> + eb->fs_info->sb->s_id, eb->start,
> + parent_transid, btrfs_header_generation(eb));
> ret = 1;
>
> /*
> @@ -617,15 +617,15 @@ static int btree_readpage_end_io_hook(struct btrfs_io_bio *io_bio,
>
> found_start = btrfs_header_bytenr(eb);
> if (found_start != eb->start) {
> - printk_ratelimited(KERN_INFO "BTRFS: bad tree block start "
> + printk_ratelimited(KERN_INFO "BTRFS (device %s): bad tree block start "
> "%llu %llu\n",
> - found_start, eb->start);
> + eb->fs_info->sb->s_id, found_start, eb->start);
> ret = -EIO;
> goto err;
> }
> if (check_tree_block_fsid(root, eb)) {
> - printk_ratelimited(KERN_INFO "BTRFS: bad fsid on block %llu\n",
> - eb->start);
> + printk_ratelimited(KERN_INFO "BTRFS (device %s): bad fsid on block %llu\n",
> + eb->fs_info->sb->s_id, eb->start);
> ret = -EIO;
> goto err;
> }
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
"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/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2014-07-04 14:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 20:41 3.15.1: kernel BUG at fs/btrfs/locking.c:269 Marc MERLIN
2014-07-03 7:47 ` Duncan
2014-07-03 8:13 ` Liu Bo
2014-07-03 8:20 ` Wang Shilong
2014-07-03 9:25 ` Liu Bo
2014-07-03 13:44 ` Marc MERLIN
2014-07-04 3:07 ` Liu Bo
2014-07-04 4:11 ` Marc MERLIN
2014-07-04 5:29 ` Wang Shilong
2014-07-04 5:48 ` Wang Shilong
2014-07-04 6:02 ` Marc MERLIN
2014-07-04 6:12 ` Wang Shilong
2014-07-04 9:59 ` [PATCH] Btrfs: print btrfs specific info for some fatal error cases Wang Shilong
2014-09-05 9:49 ` David Sterba
2014-07-04 14:02 ` Marc MERLIN [this message]
2014-07-04 6:18 ` 3.15.1: kernel BUG at fs/btrfs/locking.c:269 Wang Shilong
2014-07-04 3:50 ` Wang Shilong
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=20140704140211.GG26932@merlins.org \
--to=marc@merlins.org \
--cc=bo.li.liu@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wangsl.fnst@cn.fujitsu.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 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).