All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Tribus <lukyt@gmx.net>
To: Hans van Kranenburg <hans.van.kranenburg@mendix.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: BTRFS critical: corrupt leaf, slot offset bad; then read-only
Date: Tue, 7 Mar 2017 20:46:55 +0100	[thread overview]
Message-ID: <9b9499a7-413c-e897-4ad7-8a7eb40f3332@gmx.net> (raw)
In-Reply-To: <52a26261-b913-adb4-a926-41550d404dec@mendix.com>


Am 07.03.2017 um 15:12 schrieb Hans van Kranenburg:
> On 03/05/2017 11:50 PM, Lukas Tribus wrote:
>>
>> I upgraded btrfs-tools to 4.8.1 as 4.4 didn't have btrfs
>> inspect-internal dump-tree.
>> But I cannot find anything about 5242107641856 in the dump-tree output.
>>
>> What does that mean?
> I have no idea. It probably means it's gone. Did you use the filesystem
> read/write? Are the symptoms also gone?
>

Well I read basically everything and copied it to other drivers. Nothing 
appears corrupted
from what I can tell. I didn't write to the pool consciously, although I 
did not mount it
readonly either not that I'm thinking about it ...


btrfs check --readonly reports block corruption (and a number of "no 
inode ref" in files/folders):

Checking filesystem on /dev/mapper/sda3_crypt
UUID: f50f980e-7640-49c7-bf8d-20d55cfe6005
The following tree block(s) is corrupted in tree 261:
         tree block bytenr: 5242107641856, level: 0, node key: 
(5241902333952, 169, 0)
The following tree block(s) is corrupted in tree 263:
         tree block bytenr: 5242107641856, level: 0, node key: 
(5241902333952, 169, 0)
The following tree block(s) is corrupted in tree 6685:
         tree block bytenr: 5242107641856, level: 0, node key: 
(5241902333952, 169, 0)
The following tree block(s) is corrupted in tree 6879:
         tree block bytenr: 5242107641856, level: 0, node key: 
(5241902333952, 169, 0)
The following tree block(s) is corrupted in tree 6893:
         tree block bytenr: 5242107641856, level: 0, node key: 
(5241902333952, 169, 0)
The following tree block(s) is corrupted in tree 6896:
         tree block bytenr: 5242107641856, level: 0, node key: 
(5241902333952, 169, 0)
found 4080263675904 bytes used err is 1
total csum bytes: 0
total tree bytes: 181780480
total fs tree bytes: 0
total extent tree bytes: 178765824
btree space waste bytes: 49102341
file data blocks allocated: 1545338880
  referenced 1545338880


Not sure how btrfs check finds a corrupted block that doesn't appear in 
the dump-tree output.


And I had an additional stack trace on the new btrfs pool I was copying 
the data to:

[873067.780479] BTRFS error (device sdf3): bdev /dev/sdf3 errs: wr 0, rd 
1, flush 0, corrupt 0, gen 0
[873067.790639] BTRFS error (device sdf3): bdev /dev/sdf3 errs: wr 0, rd 
2, flush 0, corrupt 0, gen 0
[873067.800708] ------------[ cut here ]------------
[873067.800727] WARNING: CPU: 3 PID: 12942 at 
/build/linux-hwe-6_oOe5/linux-hwe-4.8.0/fs/btrfs/extent-tree.c:6954 
__btrfs_free_extent.isra.71+0x2cb/0xcc0 [btrfs]
[873067.800730] BTRFS: Transaction aborted (error -5)
[873067.800731] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs msdos 
jfs xfs algif_skcipher af_alg xen_gntdev xen_evtchn xenfs xen_privcmd 
dm_crypt intel_rapl x86_pkg_temp_thermal intel_powerclamp nls_iso8859_1 
coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel bridge stp 
llc intel_rapl_perf serio_raw lpc_ich joydev shpchp nuvoton_cir 
input_leds mei_me mei rc_core mac_hid ie31200_edac edac_core ib_iser 
rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi autofs4 uas usb_storage btrfs raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid mxm_wmi 
aesni_intel aes_x86_64 i915 glue_helper lrw i2c_algo_bit ablk_helper tg3 
cryptd drm_kms_helper syscopyarea sysfillrect
[873067.800782]  firewire_ohci ptp sysimgblt psmouse firewire_core 
fb_sys_fops crc_itu_t pps_core ahci drm libahci wmi fjes video
[873067.800791] CPU: 3 PID: 12942 Comm: screen Tainted: G W       
4.8.0-39-generic #42~16.04.1-Ubuntu
[873067.800791] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./Z77 Extreme6, BIOS P2.80 07/01/2013
[873067.800793]  0000000000000200 00000000f56bf709 ffff880259f1f908 
ffffffff8142e043
[873067.800795]  ffff880259f1f958 0000000000000000 ffff880259f1f948 
ffffffff8108313b
[873067.800797]  00001b2a59f1faa0 00000000fffffffb 000001cda76bc000 
ffff8802a9fe0d20
[873067.800798] Call Trace:
[873067.800803]  [<ffffffff8142e043>] dump_stack+0x63/0x90
[873067.800805]  [<ffffffff8108313b>] __warn+0xcb/0xf0
[873067.800807]  [<ffffffff810831bf>] warn_slowpath_fmt+0x5f/0x80
[873067.800821]  [<ffffffffc03e22ab>] 
__btrfs_free_extent.isra.71+0x2cb/0xcc0 [btrfs]
[873067.800836]  [<ffffffffc04542af>] ? 
btrfs_merge_delayed_refs+0x8f/0x6a0 [btrfs]
[873067.800846]  [<ffffffffc03e7070>] 
__btrfs_run_delayed_refs+0xb10/0x12c0 [btrfs]
[873067.800857]  [<ffffffff811ad938>] ? set_page_dirty+0x58/0xb0
[873067.800869]  [<ffffffffc0428198>] ? 
set_extent_buffer_dirty+0x78/0xd0 [btrfs]
[873067.800879]  [<ffffffffc03ea8de>] btrfs_run_delayed_refs+0x8e/0x2b0 
[btrfs]
[873067.800890]  [<ffffffffc03fefee>] commit_cowonly_roots+0xae/0x300 
[btrfs]
[873067.800901]  [<ffffffffc0470fa4>] ? 
btrfs_qgroup_account_extents+0x84/0x180 [btrfs]
[873067.800911]  [<ffffffffc0401c33>] 
btrfs_commit_transaction+0x573/0xb00 [btrfs]
[873067.800920]  [<ffffffffc040225e>] ? start_transaction+0x9e/0x4c0 [btrfs]
[873067.800930]  [<ffffffffc03fa38f>] btrfs_commit_super+0x8f/0xa0 [btrfs]
[873067.800939]  [<ffffffffc03fc577>] close_ctree+0x2b7/0x360 [btrfs]
[873067.800947]  [<ffffffffc03cbf29>] btrfs_put_super+0x19/0x20 [btrfs]
[873067.800949]  [<ffffffff8123553f>] generic_shutdown_super+0x6f/0x100
[873067.800950]  [<ffffffff81235852>] kill_anon_super+0x12/0x20
[873067.800966]  [<ffffffffc03ccde8>] btrfs_kill_super+0x18/0x110 [btrfs]
[873067.800968]  [<ffffffff81235a23>] deactivate_locked_super+0x43/0x70
[873067.800969]  [<ffffffff81235efc>] deactivate_super+0x5c/0x60
[873067.800971]  [<ffffffff8125544f>] cleanup_mnt+0x3f/0x90
[873067.800972]  [<ffffffff812554e2>] __cleanup_mnt+0x12/0x20
[873067.800974]  [<ffffffff810a22fe>] task_work_run+0x7e/0xa0
[873067.800975]  [<ffffffff81087001>] do_exit+0x2d1/0xb50
[873067.800977]  [<ffffffff8106b4f5>] ? __do_page_fault+0x265/0x4e0
[873067.800978]  [<ffffffff81087903>] do_group_exit+0x43/0xb0
[873067.800979]  [<ffffffff81087984>] SyS_exit_group+0x14/0x20
[873067.800980]  [<ffffffff8189b7f6>] entry_SYSCALL_64_fastpath+0x1e/0xa8
[873067.800981] ---[ end trace b0a630aaaf9a5946 ]---
[873067.800983] BTRFS: error (device sdf3) in __btrfs_free_extent:6954: 
errno=-5 IO failure
[873067.810114] BTRFS info (device sdf3): forced readonly
[873067.810116] BTRFS: error (device sdf3) in 
btrfs_run_delayed_refs:2960: errno=-5 IO failure
[873067.819481] BTRFS warning (device sdf3): Skipping commit of aborted 
transaction.
[873067.819482] BTRFS: error (device sdf3) in cleanup_transaction:1854: 
errno=-5 IO failure
[873067.828668] BTRFS error (device sdf3): commit super ret -5
[873067.835748] BTRFS error (device sdf3): cleaner transaction attach 
returned -30



I guess its time to rebuild this FS from scratch, unless you have a 
better idea?




Thanks, much appreciated,
Lukas


      reply	other threads:[~2017-03-07 20:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-21 14:12 BTRFS critical: corrupt leaf, slot offset bad; then read-only Lukas Tribus
2017-02-22  7:44 ` Lukas Tribus
2017-02-22 19:16   ` Lukas Tribus
2017-02-22 19:40   ` Hans van Kranenburg
2017-02-23 23:47     ` Lukas Tribus
2017-02-24  0:26       ` Hans van Kranenburg
2017-03-05 22:50         ` Lukas Tribus
2017-03-07 14:12           ` Hans van Kranenburg
2017-03-07 19:46             ` Lukas Tribus [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=9b9499a7-413c-e897-4ad7-8a7eb40f3332@gmx.net \
    --to=lukyt@gmx.net \
    --cc=hans.van.kranenburg@mendix.com \
    --cc=linux-btrfs@vger.kernel.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 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.