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: Thu, 22 Jun 2017 21:06:01 -0700 [thread overview]
Message-ID: <20170623040601.akpyyvh3dgry6nn5@merlins.org> (raw)
In-Reply-To: <e86db7c4-4953-7706-347d-983079177f37@cn.fujitsu.com>
On Thu, Jun 22, 2017 at 12:08:44PM +0800, Qu Wenruo wrote:
> > 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
>
> Well, there is only the output from extent tree.
>
> I was also expecting output from subvolue (11930) tree.
>
> It could be done by
> # btrfs-debug-tree -t 11930 | grep -C 10 3886187384832
>
> But please pay attention that, this dump may contain filenames, feel free to
> mask the filenames.
There you go:
gargamel:~# btrfs-debug-tree /dev/mapper/dsh | grep -C 10 3886187384832
dshelf1@ dshelf2@
extent compression 0 (none)
item 201 key (375444 EXTENT_DATA 1851654144) itemoff 5577 itemsize 53
extent data disk byte 5613689888768 nr 8192
extent data offset 0 nr 8192 ram 8192
extent compression 0 (none)
item 3 key (375444 EXTENT_DATA 1851744256) itemoff 16071 itemsize 53
generation 32382 type 1 (regular)
extent data disk byte 5613689888768 nr 8192
extent data offset 0 nr 8192 ram 8192
extent compression 0 (none)
item 201 key (375444 EXTENT_DATA 1851654144) itemoff 5577 itemsize 53
generation 32961 type 1 (regular)
extent data disk byte 4686293291008 nr 16384
extent data offset 0 nr 16384 ram 16384
extent compression 0 (none)
item 202 key (375444 EXTENT_DATA 1851670528) itemoff 5524 itemsize 53
generation 32382 type 1 (regular)
extent data disk byte 3886187384832 nr 81920
extent data offset 16384 nr 8192 ram 81920
extent compression 0 (none)
item 203 key (375444 EXTENT_DATA 1851678720) itemoff 5471 itemsize 53
generation 33534 type 1 (regular)
extent data disk byte 5540480962560 nr 8192
extent data offset 0 nr 8192 ram 8192
extent compression 0 (none)
item 204 key (375444 EXTENT_DATA 1851686912) itemoff 5418 itemsize 53
generation 32961 type 1 (regular)
extent data disk byte 4686293307392 nr 16384
extent data offset 8192 nr 8192 ram 16384
extent compression 0 (none)
item 205 key (375444 EXTENT_DATA 1851695104) itemoff 5365 itemsize 53
generation 32382 type 1 (regular)
extent data disk byte 3886187384832 nr 81920
extent data offset 40960 nr 8192 ram 81920
extent compression 0 (none)
item 206 key (375444 EXTENT_DATA 1851703296) itemoff 5312 itemsize 53
generation 32961 type 1 (regular)
extent data disk byte 4686293323776 nr 8192
extent data offset 0 nr 8192 ram 8192
extent compression 0 (none)
item 207 key (375444 EXTENT_DATA 1851711488) itemoff 5259 itemsize 53
generation 32382 type 1 (regular)
extent data disk byte 3886187384832 nr 81920
extent data offset 57344 nr 8192 ram 81920
extent compression 0 (none)
leaf 5715801047040 items 105 free space 8093 generation 36595 owner 11930
fs uuid 85441c59-ad11-4b25-b1fe-974f9e4acede
chunk uuid ed705b7b-2fa6-43f6-a4a1-941c8463ee68
item 0 key (375444 EXTENT_DATA 1851719680) itemoff 16230 itemsize 53
generation 34868 type 1 (regular)
extent data disk byte 5591266127872 nr 8192
extent data offset 0 nr 8192 ram 8192
extent compression 0 (none)
item 1 key (375444 EXTENT_DATA 1851727872) itemoff 16177 itemsize 53
generation 32382 type 1 (regular)
extent data disk byte 3886187384832 nr 81920
extent data offset 73728 nr 8192 ram 81920
extent compression 0 (none)
item 2 key (375444 EXTENT_DATA 1851736064) itemoff 16124 itemsize 53
generation 31782 type 1 (regular)
extent data disk byte 5922189430784 nr 106496
extent data offset 81920 nr 8192 ram 106496
extent compression 0 (none)
item 3 key (375444 EXTENT_DATA 1851744256) itemoff 16071 itemsize 53
generation 32382 type 1 (regular)
extent data disk byte 3886187466752 nr 16384
> Thanks for this one.
> And it is caused by inlined compressed extent.
>
> Lu Fengqi will send patch fixing it.
I got the patch and will test it, thank you.
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/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2017-06-23 4:06 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 14:39 4.11.3: BTRFS critical (device dm-1): unable to add free space :-17 => btrfs check --repair runs clean Marc MERLIN
2017-06-20 15:23 ` Hugo Mills
2017-06-20 15:26 ` Marc MERLIN
2017-06-20 15:36 ` Hugo Mills
2017-06-20 15:44 ` Marc MERLIN
2017-06-20 23:12 ` Marc MERLIN
2017-06-20 23:58 ` Marc MERLIN
2017-06-21 3:31 ` Chris Murphy
2017-06-21 3:43 ` Marc MERLIN
2017-06-21 15:13 ` How to fix errors that check --mode lomem finds, but --mode normal doesn't? Marc MERLIN
2017-06-21 23:22 ` Chris Murphy
2017-06-22 0:48 ` Marc MERLIN
2017-06-22 2:22 ` Qu Wenruo
2017-06-22 2:53 ` Marc MERLIN
2017-06-22 4:08 ` Qu Wenruo
2017-06-23 4:06 ` Marc MERLIN [this message]
2017-06-23 8:54 ` Lu Fengqi
2017-06-23 16:17 ` Marc MERLIN
2017-06-24 2:34 ` Marc MERLIN
2017-06-26 10:46 ` Lu Fengqi
2017-06-27 23:11 ` Marc MERLIN
2017-06-28 7:10 ` Lu Fengqi
2017-06-28 14:43 ` Marc MERLIN
2017-05-01 17:06 ` 4.11 relocate crash, null pointer Marc MERLIN
2017-05-01 18:08 ` 4.11 relocate crash, null pointer + rolling back a filesystem by X hours? Marc MERLIN
2017-05-02 1:50 ` Chris Murphy
2017-05-02 3:23 ` Marc MERLIN
2017-05-02 4:56 ` Chris Murphy
2017-05-02 5:11 ` Marc MERLIN
2017-05-02 18:47 ` btrfs check --repair: failed to repair damaged filesystem, aborting Marc MERLIN
2017-05-03 6:00 ` Marc MERLIN
2017-05-03 6:17 ` Marc MERLIN
2017-05-03 6:32 ` Roman Mamedov
2017-05-03 20:40 ` Marc MERLIN
2017-07-07 5:37 ` ctree.c:197: update_ref_for_cow: BUG_ON `ret` triggered, value -5 Marc MERLIN
2017-07-07 5:39 ` Marc MERLIN
2017-07-07 9:33 ` Lu Fengqi
2017-07-07 16:38 ` Marc MERLIN
2017-07-09 4:34 ` 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0) Marc MERLIN
2017-07-09 5:05 ` We really need a better/working btrfs check --repair Marc MERLIN
2017-07-09 6:34 ` 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0) Marc MERLIN
2017-07-09 7:57 ` Martin Steigerwald
2017-07-09 9:16 ` Paul Jones
2017-07-09 11:17 ` Duncan
2017-07-09 13:00 ` Martin Steigerwald
2017-07-29 19:29 ` Imran Geriskovan
2017-07-29 23:38 ` Duncan
2017-07-30 14:54 ` Imran Geriskovan
2017-07-31 4:53 ` Duncan
2017-07-31 20:32 ` Imran Geriskovan
2017-08-01 1:36 ` Duncan
2017-08-01 15:18 ` Imran Geriskovan
2017-07-31 21:07 ` Ivan Sizov
2017-07-31 21:17 ` Marc MERLIN
2017-07-31 21:39 ` Ivan Sizov
2017-08-01 16:41 ` Ivan Sizov
2017-07-31 22:00 ` Justin Maggard
2017-08-01 6:38 ` Marc MERLIN
2017-05-02 19:59 ` 4.11 relocate crash, null pointer + rolling back a filesystem by X hours? Kai Krakow
2017-05-02 5:01 ` Duncan
2017-05-02 19:53 ` Kai Krakow
2017-05-23 16:58 ` Marc MERLIN
2017-05-24 10:16 ` Duncan
2017-05-05 1:19 ` Qu Wenruo
2017-05-05 2:10 ` Qu Wenruo
2017-05-05 2:40 ` Marc MERLIN
2017-05-05 5:03 ` Qu Wenruo
2017-05-05 15:43 ` Marc MERLIN
2017-05-17 18:23 ` Kai Krakow
2017-05-05 1:13 ` Qu Wenruo
2017-06-29 13:36 ` How to fix errors that check --mode lomem finds, but --mode normal doesn't? Lu Fengqi
2017-06-29 15:30 ` Marc MERLIN
2017-06-30 14:59 ` Lu Fengqi
2017-06-22 4:08 ` Qu Wenruo
2017-06-21 12:04 ` 4.11.3: BTRFS critical (device dm-1): unable to add free space :-17 => btrfs check --repair runs clean Duncan
2017-06-21 3:26 ` Chris Murphy
2017-06-21 4:06 ` Marc MERLIN
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=20170623040601.akpyyvh3dgry6nn5@merlins.org \
--to=marc@merlins.org \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=quwenruo@cn.fujitsu.com \
/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.