linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
To: Marc MERLIN <marc@merlins.org>
Cc: <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 11:50:25 +0800	[thread overview]
Message-ID: <53B62481.3030606@cn.fujitsu.com> (raw)
In-Reply-To: <20140703134421.GS26932@merlins.org>

On 07/03/2014 09:44 PM, Marc MERLIN wrote:
> Thanks for the patch. Hopefully this will make it to the next 3.15.x
> kernel.
>
> I also went back to 3.14 anyway since the 'blocked for 120 seconds' look
> like another instance of deadlocks we've been discussing here.
>
> But just curious:
>
>>>> [160562.925463] parent transid verify failed on 2776298520576 wanted 41015 found 18120
> What should I be doing about this?
> Does it mean that I do have some kind of corruption/damage on my
> filesystem?
I am afraid, scrub maybe could not fix such kind of errors, all scrub 
doing is to verify whether
checksums match and if possible use good mirrors to rewrite bad one.

Such errors seem imply contention  itself is corrupted, we may have 
passed checksum
check after ending io, but we fail generation check afterwards.

So backups are always good.....:-)
>
> Also, is it possible to have all these messages state which devid they
> occurred on? I don't even know which device I should be worrying about
> right now, and although I'm running scrub now, my understanding is that
> scrub doesn't actually look at FS structures and is likely to miss this
> anyway.
To get physical device name, we still need mirror num to know which device
we are locating.

Feel free to correct me if i miss something here.:-)

Thanks,
Wang
>
> Thanks,
> Marc


      parent reply	other threads:[~2014-07-04  3:54 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               ` 3.15.1: kernel BUG at fs/btrfs/locking.c:269 Marc MERLIN
2014-07-04  6:18             ` Wang Shilong
2014-07-04  3:50       ` Wang Shilong [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=53B62481.3030606@cn.fujitsu.com \
    --to=wangsl.fnst@cn.fujitsu.com \
    --cc=bo.li.liu@oracle.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 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).