From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:53263 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751652AbcAOCgj (ORCPT ); Thu, 14 Jan 2016 21:36:39 -0500 Subject: Re: Crash on btrfs check To: "cheater00 ." , Btrfs BTRFS References: From: Qu Wenruo Message-ID: <56985B23.9040802@cn.fujitsu.com> Date: Fri, 15 Jan 2016 10:36:19 +0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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 > >