Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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 11:08:31 +0000	[thread overview]
Message-ID: <4f838a67672053e268ffce77ea800a8a@lesimple.fr> (raw)
In-Reply-To: <90cf0737-6d33-94d8-9607-0f9c371c82aa@gmx.com>

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
[  451.026353] BTRFS warning (device dm-10): leftover v1 space cache found, please use btrfs-check --clear-space-cache v1 to clean it up
[  463.501781] BTRFS info (device dm-10): balance: ended with status: -2

Regards,

Stéphane.

  reply	other threads:[~2020-12-29 11:09 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 [this message]
2020-12-29 11:30       ` Qu Wenruo
2020-12-29 12:30         ` Stéphane Lesimple
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=4f838a67672053e268ffce77ea800a8a@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