Re: How to fix errors that check --mode lomem finds, but --mode normal doesn't?

From: Marc MERLIN <marc@merlins.org>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Hugo Mills <hugo@carfax.org.uk>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: How to fix errors that check --mode lomem finds, but --mode normal doesn't?
Date: Wed, 21 Jun 2017 19:53:30 -0700	[thread overview]
Message-ID: <20170622025330.GX5303@merlins.org> (raw)
In-Reply-To: <13856431-9ee5-c13e-f2a8-860394f9aae4@cn.fujitsu.com>

[-- Attachment #1: Type: text/plain, Size: 3830 bytes --]

Ok, first it finished (almost 24H)

(...)
ERROR: root 3862 EXTENT_DATA[18170706 135168] interrupt
ERROR: root 3862 EXTENT_DATA[18170706 1048576] interrupt
ERROR: root 3864 EXTENT_DATA[109336 4096] interrupt
ERROR: errors found in fs roots
found 5544779108352 bytes used, error(s) found
total csum bytes: 5344523140
total tree bytes: 71323041792
total fs tree bytes: 59288403968
total extent tree bytes: 5378260992
btree space waste bytes: 10912166856
file data blocks allocated: 7830914256896
 referenced 6244104495104

Thanks for your reply Qu

On Thu, Jun 22, 2017 at 10:22:57AM +0800, Qu Wenruo wrote:
> >gargamel:~# btrfs check -p --mode lowmem  /dev/mapper/dshelf2
> >Checking filesystem on /dev/mapper/dshelf2
> >UUID: 85441c59-ad11-4b25-b1fe-974f9e4acede
> >ERROR: extent[3886187384832, 81920] referencer count mismatch (root: 
> >11930, owner: 375444, offset: 1851654144) wanted: 1, have: 4
> 
> This means that in extent tree, btrfs says there is only one referring 
> to this extent, but lowmem mode find 4.
> 
> It would provide great help if you could dump extent tree for it.
> # btrfs-debug-tree <dev> | grep -C 10 3886187384832

                extent data backref root 11712 objectid 375444 offset 1851572224 count 1
                extent data backref root 11276 objectid 375444 offset 1851572224 count 1
                extent data backref root 11058 objectid 375444 offset 1851572224 count 1
                extent data backref root 11494 objectid 375444 offset 1851572224 count 1
        item 37 key (3886187352064 EXTENT_ITEM 32768) itemoff 11381 itemsize 140
                extent refs 4 gen 32382 flags DATA
                extent data backref root 11712 objectid 375444 offset 1851596800 count 1
                extent data backref root 11276 objectid 375444 offset 1851596800 count 1
                extent data backref root 11058 objectid 375444 offset 1851596800 count 1
                extent data backref root 11494 objectid 375444 offset 1851596800 count 1
        item 38 key (3886187384832 EXTENT_ITEM 81920) itemoff 11212 itemsize 169
                extent refs 16 gen 32382 flags DATA
                extent data backref root 11712 objectid 375444 offset 1851654144 count 4
                extent data backref root 11276 objectid 375444 offset 1851654144 count 4
                extent data backref root 11058 objectid 375444 offset 1851654144 count 3
                extent data backref root 11494 objectid 375444 offset 1851654144 count 4
                extent data backref root 11930 objectid 375444 offset 1851654144 count 1
        item 39 key (3886187466752 EXTENT_ITEM 16384) itemoff 11043 itemsize 169
                extent refs 5 gen 32382 flags DATA
                extent data backref root 11712 objectid 375444 offset 1851744256 count 1
                extent data backref root 11276 objectid 375444 offset 1851744256 count 1

> >ERROR: errors found in extent allocation tree or chunk allocation
> >cache and super generation don't match, space cache will be invalidated
> >ERROR: root 3857 EXTENT_DATA[108864 4096] interrupt
> 
> This means that, for root 3857, inode 108864, file offset 4096, there is 
> a gap before that extent.
> In NO_HOLES mode it's allowed, but if NO_HOLES incompat flag is not set, 
> this should be a problem.
> 
> I wonder if this is a problem caused by inlined compressed file extent.
> 
> This can also be dumped by the following command.
> # btrfs-debug-tree -t 3857 <dev> | grep -C 10 108864

This one is much bigger (192KB), I've bzipped and attached it.

Thanks for having a look, I appreciate it.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

[-- Attachment #2: out.bz2 --]
[-- Type: application/octet-stream, Size: 23826 bytes --]