Re: 3.15.1: kernel BUG at fs/btrfs/locking.c:269

[Wang Shilong <wangsl.fnst@cn.fujitsu.com>]

On 07/04/2014 02:02 PM, Marc MERLIN wrote:
> On Fri, Jul 04, 2014 at 01:29:29PM +0800, Wang Shilong wrote:
>>> Well, I explained the problem, ext4 and others of course tell me which
>>> devid
>>> an error is on, hopefully btrfs will able to do so in the near future.
>> So it is ok for you to print one of btrfs filesystem device(for example
>> device name) ? maybe it is not really physical address the metadata
>> locates in, this is easier.
> Yes, the device name is great, now I can see which of my 3 filesystems has a
> problem, that's a start.
> Next would be knowing which filename this occurred in, but I understand this
> would be harder to get from that point in the code.
> Ideally scrub should be able to find that problem and report it, at least I
> would know which filesystem to rescan for errors:
>
>>> Back to the original problem, would you agree that
>>> find / -type f -print0 | xargs grep . >/dev/nul?
> I'll also have to try this to see if I get lucky with it :)
>
>> +       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));
> That looks great. Ideally all such errors would look like this.
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...

Looking at btrfs codes, if it found such error which means checksum has 
passed but generation
verification fails it  dosen't even try other mirrors if existed, so i 
supposed such kinds of errors
is fatal and could be corrected by btrfs itself..

Anyway, let me see if there are any other output even dose not output 
btrfs specific info.

Thanks,
>
> Thanks for looking into this, I appreciate it.
>
> Best,
> Marc