From: "Stéphane Lesimple" <stephane_btrfs2@lesimple.fr>
To: "Qu Wenruo" <quwenruo.btrfs@gmx.com>, "Qu Wenruo" <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: relocation: output warning message for leftover v1 space cache before aborting current data balance
Date: Tue, 29 Dec 2020 12:30:02 +0000 [thread overview]
Message-ID: <e811efd8b2936a559d665e7303ce0873@lesimple.fr> (raw)
In-Reply-To: <82e6288d-7b37-5797-13d9-f786afb33f5d@gmx.com>
December 29, 2020 12:32 PM, "Qu Wenruo" <quwenruo.btrfs@gmx.com> wrote:
> On 2020/12/29 下午7:08, Stéphane Lesimple wrote:
>
>> December 29, 2020 11:31 AM, "Qu Wenruo" <quwenruo.btrfs@gmx.com> wrote:
>>
>> # btrfs ins dump-tree -t root /dev/mapper/luks-tank-mdata | grep EXTENT_DA
>> item 27 key (51933 EXTENT_DATA 0) itemoff 9854 itemsize 53
>> item 12 key (72271 EXTENT_DATA 0) itemoff 14310 itemsize 53
>> item 25 key (74907 EXTENT_DATA 0) itemoff 12230 itemsize 53
>>> Mind to dump all those related inodes?
>>>
>>> E.g:
>>>
>>> $ btrfs ins dump-tree -t root <dev> | gerp 51933 -C 10
>>
>> Sure. I added -w to avoid grepping big numbers just containing the digits 51933:
>>
>> # btrfs ins dump-tree -t root /dev/mapper/luks-tank-mdata | grep 51933 -C 10 -w
>> generation 2614632 root_dirid 256 bytenr 42705449811968 level 2 refs 1
>> lastsnap 2614456 byte_limit 0 bytes_used 101154816 flags 0x1(RDONLY)
>> uuid 1100ff6c-45fa-824d-ad93-869c94a87c7b
>> parent_uuid 8bb8a884-ea4f-d743-8b0c-b6fdecbc397c
>> ctransid 1337630 otransid 1249372 stransid 0 rtransid 0
>> ctime 1554266422.693480985 (2019-04-03 06:40:22)
>> otime 1547877605.465117667 (2019-01-19 07:00:05)
>> drop key (0 UNKNOWN.0 0) level 0
>> item 25 key (51098 ROOT_BACKREF 5) itemoff 10067 itemsize 42
>> root backref key dirid 534 sequence 22219 name 20190119_070006_hourly.7
>> item 26 key (51933 INODE_ITEM 0) itemoff 9907 itemsize 160
>> generation 0 transid 1517381 size 262144 nbytes 30553407488
>> block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
>> sequence 116552 flags 0x1b(NODATASUM|NODATACOW|NOCOMPRESS|PREALLOC)
>> atime 0.0 (1970-01-01 01:00:00)
>> ctime 1567904822.739884119 (2019-09-08 03:07:02)
>> mtime 0.0 (1970-01-01 01:00:00)
>> otime 0.0 (1970-01-01 01:00:00)
>> item 27 key (51933 EXTENT_DATA 0) itemoff 9854 itemsize 53
>> generation 1517381 type 2 (prealloc)
>> prealloc data disk byte 34626327621632 nr 262144
>> prealloc data offset 0 nr 262144
>> item 28 key (52262 ROOT_ITEM 0) itemoff 9415 itemsize 439
>> generation 2618893 root_dirid 256 bytenr 42677048360960 level 3 refs 1
>> lastsnap 2618893 byte_limit 0 bytes_used 5557338112 flags 0x0(none)
>> uuid d0d4361f-d231-6d40-8901-fe506e4b2b53
>> ctransid 2618893 otransid 1277275 stransid 0 rtransid 0
>> ctime 1609211576.181355141 (2020-12-29 04:12:56)
>> otime 1550343531.349394412 (2019-02-16 19:58:51)
>>
>>> The point here is to show if we have INODE_ITEM here for the inode number.
>>
>> I think we do, if I understand the output correctly!
>>
>>> Although above ins dump should work, I just want to be extra sure about
>>> where the -ENOENT comes from.
>>>
>>> Would you mind to test the following debug output?
>>
>> Here you go:
>>
>> [ 438.260483] BTRFS info (device dm-10): balance: start -dvrange=34625344765952..34625344765953
>> [ 438.269018] BTRFS info (device dm-10): relocating block group 34625344765952 flags data|raid1
>> [ 450.439609] BTRFS info (device dm-10): found 167 extents, stage: move data extents
>> [ 451.026349] delete_v1_space_cache: no FILE_EXTENT found, leaf start=42676709441536
>> data_bytenr=34626327621632
>
> This means the leaf returned by find_all_leafs() is not correct?!
>
> Would you please try this one? (Need to clean up previous diff first):
Sure:
BTRFS info (device dm-10): balance: start -dvrange=34625344765952..34625344765953
BTRFS info (device dm-10): relocating block group 34625344765952 flags data|raid1
BTRFS info (device dm-10): found 167 extents, stage: move data extents
delete_v1_space_cache: no FILE_EXTENT found, leaf start=42677482782720 data_bytenr=34626327621632
BTRFS info (device dm-10): leaf 42677482782720 gen 2619699 total ptrs 38 free space 6595 owner 1
item 0 key (32735 132 726935) itemoff 15844 itemsize 439
root data bytenr 42705449844736 refs 1
item 1 key (32735 144 5) itemoff 15802 itemsize 42
item 2 key (32736 132 726938) itemoff 15363 itemsize 439
root data bytenr 42705450303488 refs 1
item 3 key (32736 144 5) itemoff 15320 itemsize 43
item 4 key (34615 132 802086) itemoff 14881 itemsize 439
root data bytenr 42705443913728 refs 1
item 5 key (34615 144 5) itemoff 14839 itemsize 42
item 6 key (34616 132 802088) itemoff 14400 itemsize 439
root data bytenr 42705445797888 refs 1
item 7 key (34616 144 5) itemoff 14357 itemsize 43
item 8 key (34688 132 804349) itemoff 13918 itemsize 439
root data bytenr 42697575448576 refs 1
item 9 key (34688 144 5) itemoff 13874 itemsize 44
item 10 key (40681 132 0) itemoff 13435 itemsize 439
root data bytenr 42705844584448 refs 1
item 11 key (40681 144 5) itemoff 13414 itemsize 21
item 12 key (46589 132 0) itemoff 12975 itemsize 439
root data bytenr 42705856479232 refs 1
item 13 key (46589 144 5) itemoff 12948 itemsize 27
item 14 key (50759 132 1239367) itemoff 12509 itemsize 439
root data bytenr 42705450270720 refs 1
item 15 key (50759 144 5) itemoff 12468 itemsize 41
item 16 key (50892 132 1243531) itemoff 12029 itemsize 439
root data bytenr 42705448812544 refs 1
item 17 key (50892 144 5) itemoff 11988 itemsize 41
item 18 key (50950 132 1245041) itemoff 11549 itemsize 439
root data bytenr 42705448779776 refs 1
item 19 key (50950 144 5) itemoff 11508 itemsize 41
item 20 key (51007 132 1246989) itemoff 11069 itemsize 439
root data bytenr 42705447649280 refs 1
item 21 key (51007 144 5) itemoff 11028 itemsize 41
item 22 key (51068 132 1248396) itemoff 10589 itemsize 439
root data bytenr 42705450156032 refs 1
item 23 key (51068 144 5) itemoff 10548 itemsize 41
item 24 key (51098 132 1249372) itemoff 10109 itemsize 439
root data bytenr 42705449811968 refs 1
item 25 key (51098 144 5) itemoff 10067 itemsize 42
item 26 key (51933 1 0) itemoff 9907 itemsize 160
inode generation 0 size 262144 mode 100600
item 27 key (51933 108 0) itemoff 9854 itemsize 53
extent data disk bytenr 34626327621632 nr 262144
extent data offset 0 nr 262144 ram 262144
item 28 key (52262 132 0) itemoff 9415 itemsize 439
root data bytenr 42677048360960 refs 1
item 29 key (52262 144 5) itemoff 9392 itemsize 23
item 30 key (52267 132 0) itemoff 8953 itemsize 439
root data bytenr 42705856806912 refs 1
item 31 key (52267 144 5) itemoff 8931 itemsize 22
item 32 key (52268 132 0) itemoff 8492 itemsize 439
root data bytenr 42678619897856 refs 1
item 33 key (52268 144 5) itemoff 8471 itemsize 21
item 34 key (52453 132 0) itemoff 8032 itemsize 439
root data bytenr 42705323196416 refs 1
item 35 key (52453 144 5) itemoff 8011 itemsize 21
item 36 key (58841 132 0) itemoff 7572 itemsize 439
root data bytenr 42677453111296 refs 1
item 37 key (58841 144 5) itemoff 7545 itemsize 27
BTRFS warning (device dm-10): leftover v1 space cache found, please use btrfs-check --clear-space-cache v1 to clean it up
BTRFS info (device dm-10): balance: ended with status: -2
Regards,
Stéphane.
next prev parent reply other threads:[~2020-12-29 12:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-29 0:38 [PATCH] btrfs: relocation: output warning message for leftover v1 space cache before aborting current data balance Qu Wenruo
2020-12-29 9:27 ` Stéphane Lesimple
2020-12-29 10:29 ` Qu Wenruo
2020-12-29 11:08 ` Stéphane Lesimple
2020-12-29 11:30 ` Qu Wenruo
2020-12-29 12:30 ` Stéphane Lesimple [this message]
2020-12-29 12:41 ` Qu Wenruo
2020-12-29 12:51 ` Stéphane Lesimple
2020-12-29 13:06 ` Qu Wenruo
2020-12-29 13:17 ` Stéphane Lesimple
2020-12-30 5:49 ` Qu Wenruo
2020-12-30 8:39 ` Stéphane Lesimple
2020-12-30 0:56 ` Qu Wenruo
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=e811efd8b2936a559d665e7303ce0873@lesimple.fr \
--to=stephane_btrfs2@lesimple.fr \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox