Re: Counts for qgroup id are different

[JMinson <minsonj2016@gmail.com>]

I got this same error when running the rescan on an internal hd with a 
btrfs formatted lv so its not usb specific .


rsync'ing to external usb drive daily as described below


On 10/7/20 7:14 AM, Qu Wenruo wrote:
> On 2020/10/7 下午6:58, JMinson wrote:
>> 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
> This is completely unrelated to qgroup then.
>
> According to the code, it looks like some lock schema problem.
> At least for the qgroup part it should be fine now.
>
> For the new part, unless you're a developer, you can just ignore it.
> Or could you provide the workload for us to reproduce?
> Just your regular backup workload?
>
> Thanks,
> Qu
>
>> 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
>>>