Re: kernel BUG at fs/btrfs/extent-tree.c:5038 (linux 3.4.7)

[Olivier Bonvalet <btrfs.list@daevel.fr>]

On 04/08/2012 00:41, Olivier Bonvalet wrote:
> On 02/08/2012 18:18, Olivier Bonvalet wrote:
>> On 02/08/2012 15:53, David Sterba wrote:
>>> On Thu, Aug 02, 2012 at 03:41:03PM +0200, Olivier Bonvalet wrote:
>>>> Yes... it's a copy from my /var/log/kern.log. Is it really "disabled" ?
>>>
>>> I was mistaken, it really is enabled unconditionally in ctree.h:55.
>>> Josef says that the V0 extent refs are not used for a long time, so the
>>> question is how did they appear in your filesystem. Did you switch to a
>>> new kernel from a very old one?
>>>
>>>
>>> david
>>> -- 
>>> 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
>>>
>>
>> mmm I have upgraded that system every two months, but the first setup is from april 2011 I think.
>>
>> Should I start a "scrub" on all that systems installed a long time ago ?
>> -- 
>> 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
>>
> 
> So after a hard reboot that filesystem is not mountable anymore :
> 
> Aug  4 00:40:06 backup2 kernel: [  614.826124] device fsid a5dfe512-c8a3-46f0-bc8c-6365b8eccdcb devid 1 transid 110423 /dev/mapper/vg--backupplug-backup
> Aug  4 00:40:06 backup2 kernel: [  614.827934] btrfs: force zlib compression
> Aug  4 00:40:06 backup2 kernel: [  614.827943] btrfs: not using ssd allocation scheme
> Aug  4 00:40:06 backup2 kernel: [  614.827950] btrfs: enabling auto recoveryparent transid verify failed on 615015833600 wanted 110423 found 110424
> Aug  4 00:40:06 backup2 kernel: [  614.933613] parent transid verify failed on 615015833600 wanted 110423 found 110424
> Aug  4 00:40:06 backup2 kernel: [  614.934700] btrfs read error corrected: ino 1 off 615015833600 (dev /dev/mapper/vg--backupplug-backup sector 1209083504)
> Aug  4 00:40:06 backup2 kernel: [  614.934716] Failed to read block groups: -5
> Aug  4 00:40:07 backup2 kernel: [  614.952684] btrfs: open_ctree failed
> 
> 
> Is there something I can do to fix that ? (the mount option "recovery" didn't help here)
> 
> thanks,
> 
> Olivier
> --
> 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
> 


and btrfsck doesn't help :

# btrfsck /dev/vg-backupplug/backup
parent transid verify failed on 615015833600 wanted 110423 found 110424
Ignoring transid failure
checking extents
Extent back ref already exists for 615015841792 parent 0 root 2
bad block 615015841792
parent transid verify failed on 615015833600 wanted 110423 found 110424
Ignoring transid failure
parent transid verify failed on 615015833600 wanted 110423 found 110424
Ignoring transid failure
[...]
parent transid verify failed on 615015866368 wanted 110423 found 110424
Ignoring transid failure
leaf parent key incorrect 615015849984
bad block 615015849984
leaf parent key incorrect 615015858176
bad block 615015858176
parent transid verify failed on 615015833600 wanted 110423 found 110424
Ignoring transid failure
[...]
parent transid verify failed on 615015866368 wanted 110423 found 110424
Ignoring transid failure
leaf parent key incorrect 615015866368
bad block 615015866368
parent transid verify failed on 615015833600 wanted 110423 found 110424
Ignoring transid failure
btrfsck: disk-io.c:441: find_and_setup_root: Assertion `!(ret)' failed.
Abandon
#


Data can be restored thanks to btrfs-restore tool ; but is there really no way to fix the filesystem ?
(I also tried btrfs-zero-log)

Olivier