From: JMinson <minsonj2016@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
BTRFS Kernel <linux-btrfs@vger.kernel.org>
Subject: Re: Counts for qgroup id are different
Date: Wed, 7 Oct 2020 06:58:49 -0400 [thread overview]
Message-ID: <91df37d7-d173-f264-6a2b-22649b0f7e68@gmail.com> (raw)
In-Reply-To: <9ded0048-a480-8873-899d-576210490606@gmx.com>
Good News / Bad News
The good news is that btrfs quota rescan /Daily cleared the Counts for
qgroup id are different error .
The bad news is that during the rescan these errors are being generated:
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145760] ------------[ cut
here ]------------
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145766] WARNING: CPU: 4
PID: 4850 at fs/fs-writeback.c:2466 __writeback_inodes_sb_nr+0xbf/0xd0
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145766] Modules linked in:
ccm rfcomm cmac algif_hash algif_skcipher af_alg bnep
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio
snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec
snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event
nls_iso8859_1 snd_rawmidi snd_seq iwlmvm snd_seq_device edac_mce_amd
mac80211 kvm_amd ccp snd_timer libarc4 kvm eeepc_wmi iwlwifi asus_wmi
sparse_keymap wmi_bmof btusb snd k10temp cfg80211 btrtl btbcm btintel
joydev soundcore input_leds bluetooth ecdh_generic ecc mac_hid
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4
btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy
async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath
linear hid_logitech_hidpp uas usb_storage hid_logitech_dj hid_generic
usbhid hid amdgpu crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
amd_iommu_v2 gpu_sched aesni_intel i2c_algo_bit ttm crypto_simd
drm_kms_helper cryptd glue_helper syscopyarea
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145791] sysfillrect
sysimgblt nvme fb_sys_fops i2c_piix4 drm nvme_core ahci libahci wmi
video gpio_amdpt gpio_generic
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145796] CPU: 4 PID: 4850
Comm: btrfs-transacti Tainted: G W 5.4.0-48-generic #52-Ubuntu
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145797] Hardware name:
System manufacturer System Product Name/PRIME B450M-A, BIOS 2202 07/14/2020
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145799] RIP:
0010:__writeback_inodes_sb_nr+0xbf/0xd0
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145800] Code: b6 d1 48 8d
75 b0 e8 80 fc ff ff 4c 89 e7 e8 e8 fb ff ff 48 8b 45 f0 65 48 33 04 25
28 00 00 00 75 0c 48 83 c4 58 41 5c 5d c3 <0f> 0b eb ce e8 48 c4 d8 ff
0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145800] RSP:
0018:ffffb9ac82a5fdb0 EFLAGS: 00010246
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145801] RAX:
0000000000000000 RBX: 0000000000000125 RCX: 0000000000000000
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145802] RDX:
0000000000000002 RSI: 00000000000122ba RDI: ffff9a07f0396800
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145802] RBP:
ffffb9ac82a5fe10 R08: ffff9a07f0395800 R09: ffffb9ac82a5fdd0
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145803] R10:
0000000000000000 R11: 0000000000000000 R12: ffffb9ac82a5fdb0
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145803] R13:
0000000000000002 R14: ffff9a0842aba800 R15: 0000000000000000
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145804] FS:
0000000000000000(0000) GS:ffff9a0850900000(0000) knlGS:0000000000000000
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145804] CS: 0010 DS: 0000
ES: 0000 CR0: 0000000080050033
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145805] CR2:
00007fe990379000 CR3: 00000003fff9e000 CR4: 00000000003406e0
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145805] Call Trace:
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145808]
writeback_inodes_sb+0x4b/0x60
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145820]
btrfs_commit_transaction+0x2f6/0x960 [btrfs]
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145828] ?
start_transaction+0xb7/0x510 [btrfs]
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145830] ?
del_timer_sync+0x30/0x40
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145838]
transaction_kthread+0x146/0x190 [btrfs]
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145840] kthread+0x104/0x140
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145847] ?
btrfs_cleanup_transaction+0x530/0x530 [btrfs]
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145848] ?
kthread_park+0x90/0x90
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145850] ret_from_fork+0x22/0x40
Oct 7 06:25:27 linux-desktop kernel: [ 4001.145851] ---[ end trace
21d9e8c753568b19 ]---
On 10/6/20 8:13 PM, Qu Wenruo wrote:
>
> On 2020/10/6 下午10:27, JMinson wrote:
>> Linux linux-desktop 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49
>> UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
>>
>> btrfs-progs v5.4.1
>>
>> Label: 'Daily' uuid: 1426edb8-4fed-419a-b0f1-d131b97224fd
>> Total devices 1 FS bytes used 1.13TiB
>> devid 1 size 1.82TiB used 1.14TiB path /dev/sdb
>>
>>
>> I use rsync to backup to an external btrfs formatted usb drive . The
>> process is :
>>
>>
>> mount btrfs volume "/Daily"
>>
>> take a snapshot of subvolume "BackupRoot" and give the snapshot a name
>> like "snap@BackupRoot-2020-10-05-Oct-1601938835"
>>
>> run rsync with the destination being "/Daily/BackupRoot"
>>
>> unmount the btrfs volume "/Daily"
>>
>> I've been using this procedure for about 6 months and is far as I know
>> all the data is good . However I discovered yesterday that when I run
>> btrfsck I get 1 or more of these
>>
>> Counts for qgroup id: 0/1561 are different
>> our: referenced 1051233288192 referenced compressed
>> 1051233288192
>> disk: referenced 1046914453504 referenced compressed
>> 1046914453504
>> diff: referenced 4318834688 referenced compressed 4318834688
> This means btrfs qgroup on-disk is smaller than what btrfs check think is.
>
> Is there any subvolume deletion involved in this case?
> IIRC btrfs kernel and btrfs-check has different opinion on half-dropped
> subvolumes. But when the subvolume is fully dropped, then everything
> goes back into sync again.
>
>> our: exclusive 1206681600 exclusive compressed 1206681600
>> disk: exclusive 1206681600 exclusive compressed 1206681600
> But exclusive is correct, thus it doesn't look like regular qgroup error.
>
>>
>> Is this something to be concerned about ?
> Normally you don't need to be concerned.
>
> If you really don't like this, you can just trigger a qgroup rescan and
> it will be handled well.
>
> Another thing is, if you're running btrfs check with --force, on running
> fs, it could give false alert.
>
> Thanks,
> Qu
>
next prev parent reply other threads:[~2020-10-07 10:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 14:27 Counts for qgroup id are different JMinson
2020-10-07 0:13 ` Qu Wenruo
2020-10-07 10:58 ` JMinson [this message]
2020-10-07 11:14 ` Qu Wenruo
2020-10-07 12:38 ` JMinson
2020-10-07 12:48 ` JMinson
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=91df37d7-d173-f264-6a2b-22649b0f7e68@gmail.com \
--to=minsonj2016@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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;
as well as URLs for NNTP newsgroup(s).