From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: "cheater00 ." <cheater00@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Crash on btrfs check
Date: Fri, 15 Jan 2016 10:36:19 +0800 [thread overview]
Message-ID: <56985B23.9040802@cn.fujitsu.com> (raw)
In-Reply-To: <CA+9GZUjeXhvb0xHCrfxg3F+Os55EzSq+66009EAbqztwQM-VVQ@mail.gmail.com>
cheater00 . wrote on 2016/01/15 03:25 +0100:
> Hi guys,
> I have a particularly full btrfs (nearly all of 6TB used on a disk).
> This is different than the fs I've experienced the resize bug on
> recently.
>
> btrfs check crashes on it:
>
> # btrfs check /dev/sdb1
> Checking filesystem on /dev/sdb1
> UUID: 95db96b3-96fe-4a12-810c-27c1dbd30b0d
> checking extents
> extent_io.c:543: __alloc_extent_buffer: Assertion failed.
> btrfs[0x80558a3]
> btrfs[0x8092971]
> btrfs(alloc_extent_buffer+0xb7)[0x8093494]
> btrfs(btrfs_find_create_tree_block+0x2b)[0x8083785]
> btrfs(read_tree_block+0x32)[0x808503f]
> btrfs(read_node_slot+0x63)[0x807f430]
> btrfs(btrfs_search_slot+0xb47)[0x8081a28]
> btrfs(btrfs_lookup_extent_info+0xd6)[0x808a0df]
> btrfs[0x806c13a]
> btrfs[0x806d95e]
> btrfs[0x806e5cb]
> btrfs(cmd_check+0x10f8)[0x8070fee]
> btrfs(main+0x14d)[0x8055acb]
> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb74f0a83]
> btrfs[0x8055af8]
>
>
>
> $ uname -a
> Linux SX20S 4.4.0-040400-generic #201601101930 SMP Mon Jan 11 00:49:33
> UTC 2016 i686 i686 i686 GNU/Linux
>
> $ btrfs --version
> btrfs-progs v4.3
>
> # btrfs fi show /dev/sdb1
> Label: 'A' uuid: 95db96b3-96fe-4a12-810c-27c1dbd30b0d
> Total devices 1 FS bytes used 5.41TiB
> devid 1 size 5.46TiB used 5.46TiB path /dev/sdb1
>
> # btrfs-show-super /dev/sdb1
> superblock: bytenr=65536, device=/dev/sdb1
> ---------------------------------------------------------
> csum 0x116b97f0 [match]
> bytenr 65536
> flags 0x1
> ( WRITTEN )
> magic _BHRfS_M [match]
> fsid 95db96b3-96fe-4a12-810c-27c1dbd30b0d
> label P
> generation 128737
> root 43384832
> sys_array_size 226
> chunk_root_generation 106809
> root_level 1
> chunk_root 20971520
> chunk_root_level 1
> log_root 0
> log_root_transid 0
> log_root_level 0
> total_bytes 6001173463040
> bytes_used 5948325072896
> sectorsize 4096
> nodesize 16384
> leafsize 16384
> stripesize 4096
> root_dir 6
> num_devices 1
> compat_flags 0x0
> compat_ro_flags 0x0
> incompat_flags 0x61
> ( MIXED_BACKREF |
> BIG_METADATA |
> EXTENDED_IREF )
> csum_type 0
> csum_size 4
> cache_generation 128737
> uuid_tree_generation 128737
> dev_item.uuid e2a8e731-b28c-437b-8cb9-583bb96aea5f
> dev_item.fsid 95db96b3-96fe-4a12-810c-27c1dbd30b0d [match]
> dev_item.type 0
> dev_item.total_bytes 6001173463040
> dev_item.bytes_used 6001173463040
> dev_item.io_align 4096
> dev_item.io_width 4096
> dev_item.sector_size 4096
> dev_item.devid 1
> dev_item.dev_group 0
> dev_item.seek_speed 0
> dev_item.bandwidth 0
> dev_item.generation 0
>
> # btrfs fi usage A
> Overall:
> Device size: 5.46TiB
> Device allocated: 5.46TiB
> Device unallocated: 0.00B
> Device missing: 0.00B
> Used: 5.42TiB
> Free (estimated): 35.41GiB (min: 35.41GiB)
> Data ratio: 1.00
> Metadata ratio: 2.00
> Global reserve: 512.00MiB (used: 0.00B)
>
> Data,single: Size:5.43TiB, Used:5.40TiB
> /dev/sdb1 5.43TiB
>
> Metadata,single: Size:8.00MiB, Used:0.00B
> /dev/sdb1 8.00MiB
>
> Metadata,DUP: Size:12.50GiB, Used:11.22GiB
> /dev/sdb1 25.00GiB
>
> System,single: Size:4.00MiB, Used:0.00B
> /dev/sdb1 4.00MiB
>
> System,DUP: Size:8.00MiB, Used:608.00KiB
> /dev/sdb1 16.00MiB
>
> Unallocated:
> /dev/sdb1 0.00B
>
> dmesg is showing a lot of stuff like this, but it only started doing
> this when I upgraded to linux 4.4, whereas before on 4.3 this didn't
> happen:
>
> [56319.486446] BTRFS critical (device sdb1): entry offset
> 6102519574528, bytes 20480, bitmap no
> [56319.486447] BTRFS critical (device sdb1): entry offset
> 6102527688704, bytes 24576, bitmap no
> [56319.486448] BTRFS critical (device sdb1): entry offset
> 6102528040960, bytes 8192, bitmap no
> [56319.486450] BTRFS critical (device sdb1): entry offset
> 6102536241152, bytes 8192, bitmap no
> [56319.486451] BTRFS critical (device sdb1): entry offset
> 6102561120256, bytes 8192, bitmap no
> [56319.486452] BTRFS critical (device sdb1): entry offset
> 6102590480384, bytes 4096, bitmap no
> [56319.486453] BTRFS critical (device sdb1): entry offset
> 6102620999680, bytes 12288, bitmap no
> [56319.486454] BTRFS critical (device sdb1): entry offset
> 6102633365504, bytes 16384, bitmap no
> [56319.486455] BTRFS info (device sdb1): block group has cluster?: no
> [56319.486456] BTRFS info (device sdb1): 1 blocks of free space at or
> bigger than bytes is
And this dmesg is not a big problem, just means space cache is wrong.
Normally mount it with clear_cache should be able to make it disappear.
Thanks,
Qu
> --
> 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
>
>
next prev parent reply other threads:[~2016-01-15 2:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-15 2:25 Crash on btrfs check cheater00 .
2016-01-15 2:31 ` Qu Wenruo
2016-01-15 2:36 ` Qu Wenruo [this message]
2016-01-15 13:56 ` cheater00 .
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=56985B23.9040802@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=cheater00@gmail.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 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).