* fsck lowmem mode only: ERROR: errors found in fs roots @ 2018-08-30 16:47 Christoph Anton Mitterer 2018-08-31 2:33 ` Su Yue 0 siblings, 1 reply; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-08-30 16:47 UTC (permalink / raw) To: Btrfs BTRFS Hey. I've the following on a btrfs that's basically the system fs for my notebook: When booting from a USB stick with: # uname -a Linux heisenberg 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 GNU/Linux # btrfs --version btrfs-progs v4.17 ... a lowmem mode fsck gives no error: # btrfs check --mode=lowmem /dev/mapper/system ; echo $? Checking filesystem on /dev/mapper/system UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c checking extents checking free space cache checking fs roots ERROR: errors found in fs roots found 495910952960 bytes used, error(s) found total csum bytes: 481840472 total tree bytes: 2388819968 total fs tree bytes: 1651097600 total extent tree bytes: 161841152 btree space waste bytes: 446707102 file data blocks allocated: 6651878428672 referenced 542320984064 1 ... while a normal mode fsck doesn't give one: # btrfs check /dev/mapper/system ; echo $? Checking filesystem on /dev/mapper/system UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c checking extents checking free space cache checking fs roots checking only csum items (without verifying data) checking root refs found 495910952960 bytes used, no error found total csum bytes: 481840472 total tree bytes: 2388819968 total fs tree bytes: 1651097600 total extent tree bytes: 161841152 btree space waste bytes: 446707102 file data blocks allocated: 6651878428672 referenced 542320984064 0 There were no unusual kernel log messages. Back in the normal system (no longer USB)... I spottet this: Aug 30 18:31:29 heisenberg kernel: BTRFS info (device dm-0): the free space cache file (22570598400) is invalid, skip it but not sure whether it's related (probably not)... and I haven't seen such a free space cache file issue (or any other btrfs errors) in a long while (I usually watch my kernel log once after booting has finished). Any ideas? Perhaps it's just yet another lowmem false positive... anything I can help in debugging this? Apart from this I haven't noticed any corruptions recently... just about to make a full backup of the fs (or better said a rw snapshot of the most of the data) with tar, so most data will be read soon at least once... an I would probably notice any further errors that are otherwise silent. Cheers, Chris. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-08-30 16:47 fsck lowmem mode only: ERROR: errors found in fs roots Christoph Anton Mitterer @ 2018-08-31 2:33 ` Su Yue 2018-09-03 20:24 ` Christoph Anton Mitterer 0 siblings, 1 reply; 17+ messages in thread From: Su Yue @ 2018-08-31 2:33 UTC (permalink / raw) To: Christoph Anton Mitterer, Btrfs BTRFS; +Cc: Su Yue Thank for the report. On 08/31/2018 12:47 AM, Christoph Anton Mitterer wrote: > Hey. > > I've the following on a btrfs that's basically the system fs for my > notebook: > > > When booting from a USB stick with: > # uname -a > Linux heisenberg 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 > (2018-08-18) x86_64 GNU/Linux > > # btrfs --version > btrfs-progs v4.17 > > ... a lowmem mode fsck gives no error: > > # btrfs check --mode=lowmem /dev/mapper/system ; echo $? > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > checking extents > checking free space cache > checking fs roots > ERROR: errors found in fs roots > found 495910952960 bytes used, error(s) found > total csum bytes: 481840472 > total tree bytes: 2388819968 > total fs tree bytes: 1651097600 > total extent tree bytes: 161841152 > btree space waste bytes: 446707102 > file data blocks allocated: 6651878428672 > referenced 542320984064 > 1 > > ... while a normal mode fsck doesn't give one: > > # btrfs check /dev/mapper/system ; echo $? > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > checking extents > checking free space cache > checking fs roots > checking only csum items (without verifying data) > checking root refs > found 495910952960 bytes used, no error found > total csum bytes: 481840472 > total tree bytes: 2388819968 > total fs tree bytes: 1651097600 > total extent tree bytes: 161841152 > btree space waste bytes: 446707102 > file data blocks allocated: 6651878428672 > referenced 542320984064 > 0 > > There were no unusual kernel log messages. > > Humm, I think it's a bug of lowmem mode. After looking through releated codes, I can't tell the cause. Can you please fetch btrfs-progs from my repo and run lowmem check in readonly? Repo: https://github.com/Damenly/btrfs-progs/tree/lowmem_debug It's based on v4.17.1 plus additonal output for debug only. > Back in the normal system (no longer USB)... I spottet this: > Aug 30 18:31:29 heisenberg kernel: BTRFS info (device dm-0): the free > space cache file (22570598400) is invalid, skip it > > but not sure whether it's related (probably not)... and I haven't seen > such a free space cache file issue (or any other btrfs errors) in a > long while (I usually watch my kernel log once after booting has > finished). >BTW, what's the mount option of USB? > > Any ideas? Perhaps it's just yet another lowmem false positive... > anything I can help in debugging this? > > > Apart from this I haven't noticed any corruptions recently... just > about to make a full backup of the fs (or better said a rw snapshot of > the most of the data) with tar, so most data will be read soon at least > once... an I would probably notice any further errors that are > otherwise silent. > Don't worry, since normal check didn't report any error, it may be just a false alert. Su > > Cheers, > Chris. > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-08-31 2:33 ` Su Yue @ 2018-09-03 20:24 ` Christoph Anton Mitterer 2018-09-04 9:14 ` Qu Wenruo 2018-09-05 7:04 ` Su Yue 0 siblings, 2 replies; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-09-03 20:24 UTC (permalink / raw) To: Su Yue, Btrfs BTRFS; +Cc: Su Yue Hey. On Fri, 2018-08-31 at 10:33 +0800, Su Yue wrote: > Can you please fetch btrfs-progs from my repo and run lowmem check > in readonly? > Repo: https://github.com/Damenly/btrfs-progs/tree/lowmem_debug > It's based on v4.17.1 plus additonal output for debug only. I've adapted your patch to 4.17 from Debian (i.e. not the 4.17.1). First I ran it again with the pristine 4.17 from Debian: # btrfs check --mode=lowmem /dev/mapper/system ; echo $? Checking filesystem on /dev/mapper/system UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c checking extents checking free space cache checking fs roots ERROR: errors found in fs roots found 435924422656 bytes used, error(s) found total csum bytes: 423418948 total tree bytes: 2218328064 total fs tree bytes: 1557168128 total extent tree bytes: 125894656 btree space waste bytes: 429599230 file data blocks allocated: 5193373646848 referenced 555255164928 [ 1248.687628] ------------[ cut here ]------------ [ 1248.688352] generic_make_request: Trying to write to read-only block-device dm-0 (partno 0) [ 1248.689127] WARNING: CPU: 3 PID: 933 at /build/linux-LgHyGB/linux-4.17.17/block/blk-core.c:2180 generic_make_request_checks+0x43d/0x610 [ 1248.689909] Modules linked in: dm_crypt algif_skcipher af_alg dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek intel_rapl snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp i915 iwlwifi btusb coretemp btrtl btbcm uvcvideo kvm_intel snd_hda_intel btintel videobuf2_vmalloc bluetooth snd_hda_codec kvm videobuf2_memops videobuf2_v4l2 videobuf2_common cfg80211 snd_hda_core irqbypass videodev jitterentropy_rng drm_kms_helper crct10dif_pclmul snd_hwdep crc32_pclmul drbg ghash_clmulni_intel intel_cstate snd_pcm ansi_cprng ppdev intel_uncore drm media ecdh_generic iTCO_wdt snd_timer iTCO_vendor_support rtsx_pci_ms crc16 snd intel_rapl_perf memstick joydev mei_me rfkill evdev soundcore sg parport_pc pcspkr serio_raw fujitsu_laptop mei i2c_algo_bit parport shpchp sparse_keymap pcc_cpufreq lpc_ich button [ 1248.693639] video battery ac ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod uas usb_storage crc32c_intel rtsx_pci_sdmmc mmc_core ahci xhci_pci libahci aesni_intel ehci_pci aes_x86_64 libata crypto_simd xhci_hcd ehci_hcd cryptd glue_helper psmouse i2c_i801 scsi_mod rtsx_pci e1000e usbcore usb_common [ 1248.696956] CPU: 3 PID: 933 Comm: btrfs Not tainted 4.17.0-3-amd64 #1 Debian 4.17.17-1 [ 1248.698118] Hardware name: FUJITSU LIFEBOOK E782/FJNB253, BIOS Version 2.11 07/15/2014 [ 1248.699299] RIP: 0010:generic_make_request_checks+0x43d/0x610 [ 1248.700495] RSP: 0018:ffffac89827c7d88 EFLAGS: 00010286 [ 1248.701702] RAX: 0000000000000000 RBX: ffff98f4848a9200 RCX: 0000000000000006 [ 1248.702930] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff98f49e2d6730 [ 1248.704170] RBP: ffff98f484f6d460 R08: 000000000000033e R09: 0000000000aaaaaa [ 1248.705422] R10: ffffac89827c7e60 R11: 00000000ffffffff R12: 0000000000000000 [ 1248.706675] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 [ 1248.707928] FS: 00007f92842018c0(0000) GS:ffff98f49e2c0000(0000) knlGS:0000000000000000 [ 1248.709190] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1248.710448] CR2: 000055fc6fe1a5b0 CR3: 0000000407f62001 CR4: 00000000001606e0 [ 1248.711707] Call Trace: [ 1248.712960] ? do_writepages+0x4b/0xe0 [ 1248.714201] ? blkdev_readpages+0x20/0x20 [ 1248.715441] ? do_writepages+0x4b/0xe0 [ 1248.716684] generic_make_request+0x64/0x400 [ 1248.717935] ? finish_wait+0x80/0x80 [ 1248.719181] ? mempool_alloc+0x67/0x1a0 [ 1248.720425] ? submit_bio+0x6c/0x140 [ 1248.721663] submit_bio+0x6c/0x140 [ 1248.722902] submit_bio_wait+0x53/0x80 [ 1248.724139] blkdev_issue_flush+0x7c/0xb0 [ 1248.725377] blkdev_fsync+0x2f/0x40 [ 1248.726612] do_fsync+0x38/0x60 [ 1248.727849] __x64_sys_fsync+0x10/0x20 [ 1248.729086] do_syscall_64+0x55/0x110 [ 1248.730323] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1248.731565] RIP: 0033:0x7f928354d161 [ 1248.732805] RSP: 002b:00007ffd35e3f5d8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a [ 1248.734067] RAX: ffffffffffffffda RBX: 000055fc09c0c260 RCX: 00007f928354d161 [ 1248.735342] RDX: 000055fc09c13e28 RSI: 000055fc0899f820 RDI: 0000000000000004 [ 1248.736614] RBP: 000055fc09c0c2d0 R08: 0000000000000005 R09: 000055fc09c0da70 [ 1248.738001] R10: 000000000000009e R11: 0000000000000246 R12: 0000000000000000 [ 1248.739272] R13: 000055fc0899d213 R14: 000055fc09c0c290 R15: 0000000000000001 [ 1248.740542] Code: 24 54 03 00 00 48 8d 74 24 08 48 89 df c6 05 3e 03 d9 00 01 e8 d5 63 01 00 44 89 e2 48 89 c6 48 c7 c7 80 e1 e6 ad e8 a3 4e d1 ff <0f> 0b 4c 8b 63 08 e9 7b fc ff ff 80 3d 15 03 d9 00 00 0f 85 94 [ 1248.741909] ---[ end trace c2f580dbd579028c ]--- 1 Not really sure why btrfs-check apparently tries to write to the device (I've had set it blockdev --setro). And with your patch: # btrfs check --mode=lowmem /dev/mapper/system ; echo $? checking extents checking free space cache checking fs roots ERROR: errors found in fs roots Checking filesystem on /dev/mapper/system UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c DEBUG: error before walking while checking fs root 3 ret -694376768 DEBUG: normal error in walking while checking node 125988438016 fs root 257 ret 524296 DEBUG: error in checking fs root 257 ret 524296 DEBUG: normal error in walking while checking node 230148259840 fs root 743 ret 524296 DEBUG: error in checking fs root 743 ret 524296 DEBUG: error in checking fs roots ret: found 435924422656 bytes used, error(s) found total csum bytes: 423418948 total tree bytes: 2218328064 total fs tree bytes: 1557168128 total extent tree bytes: 125894656 btree space waste bytes: 429599230 file data blocks allocated: 5193373646848 referenced 555255164928 1 Interestingly it doesn't try to write again (or the kernel doesn't just print another call trace this time). Cheers, Chris. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-09-03 20:24 ` Christoph Anton Mitterer @ 2018-09-04 9:14 ` Qu Wenruo 2018-09-04 11:45 ` Christoph Anton Mitterer 2018-09-05 7:04 ` Su Yue 1 sibling, 1 reply; 17+ messages in thread From: Qu Wenruo @ 2018-09-04 9:14 UTC (permalink / raw) To: Christoph Anton Mitterer, Su Yue, Btrfs BTRFS; +Cc: Su Yue On 2018/9/4 上午4:24, Christoph Anton Mitterer wrote: > Hey. > > > On Fri, 2018-08-31 at 10:33 +0800, Su Yue wrote: >> Can you please fetch btrfs-progs from my repo and run lowmem check >> in readonly? >> Repo: https://github.com/Damenly/btrfs-progs/tree/lowmem_debug >> It's based on v4.17.1 plus additonal output for debug only. > > I've adapted your patch to 4.17 from Debian (i.e. not the 4.17.1). > > > First I ran it again with the pristine 4.17 from Debian: > # btrfs check --mode=lowmem /dev/mapper/system ; echo $? > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > checking extents > checking free space cache > checking fs roots > ERROR: errors found in fs roots > found 435924422656 bytes used, error(s) found > total csum bytes: 423418948 > total tree bytes: 2218328064 > total fs tree bytes: 1557168128 > total extent tree bytes: 125894656 > btree space waste bytes: 429599230 > file data blocks allocated: 5193373646848 > referenced 555255164928 > [ 1248.687628] ------------[ cut here ]------------ > [ 1248.688352] generic_make_request: Trying to write to read-only block-device dm-0 (partno 0) > [ 1248.689127] WARNING: CPU: 3 PID: 933 at /build/linux-LgHyGB/linux-4.17.17/block/blk-core.c:2180 generic_make_request_checks+0x43d/0x610 > [ 1248.689909] Modules linked in: dm_crypt algif_skcipher af_alg dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek intel_rapl snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp i915 iwlwifi btusb coretemp btrtl btbcm uvcvideo kvm_intel snd_hda_intel btintel videobuf2_vmalloc bluetooth snd_hda_codec kvm videobuf2_memops videobuf2_v4l2 videobuf2_common cfg80211 snd_hda_core irqbypass videodev jitterentropy_rng drm_kms_helper crct10dif_pclmul snd_hwdep crc32_pclmul drbg ghash_clmulni_intel intel_cstate snd_pcm ansi_cprng ppdev intel_uncore drm media ecdh_generic iTCO_wdt snd_timer iTCO_vendor_support rtsx_pci_ms crc16 snd intel_rapl_perf memstick joydev mei_me rfkill evdev soundcore sg parport_pc pcspkr serio_raw fujitsu_laptop mei i2c_algo_bit parport shpchp sparse_keymap pcc_cpufreq lpc_ich button > [ 1248.693639] video battery ac ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod uas usb_storage crc32c_intel rtsx_pci_sdmmc mmc_core ahci xhci_pci libahci aesni_intel ehci_pci aes_x86_64 libata crypto_simd xhci_hcd ehci_hcd cryptd glue_helper psmouse i2c_i801 scsi_mod rtsx_pci e1000e usbcore usb_common > [ 1248.696956] CPU: 3 PID: 933 Comm: btrfs Not tainted 4.17.0-3-amd64 #1 Debian 4.17.17-1 > [ 1248.698118] Hardware name: FUJITSU LIFEBOOK E782/FJNB253, BIOS Version 2.11 07/15/2014 > [ 1248.699299] RIP: 0010:generic_make_request_checks+0x43d/0x610 > [ 1248.700495] RSP: 0018:ffffac89827c7d88 EFLAGS: 00010286 > [ 1248.701702] RAX: 0000000000000000 RBX: ffff98f4848a9200 RCX: 0000000000000006 > [ 1248.702930] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff98f49e2d6730 > [ 1248.704170] RBP: ffff98f484f6d460 R08: 000000000000033e R09: 0000000000aaaaaa > [ 1248.705422] R10: ffffac89827c7e60 R11: 00000000ffffffff R12: 0000000000000000 > [ 1248.706675] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 > [ 1248.707928] FS: 00007f92842018c0(0000) GS:ffff98f49e2c0000(0000) knlGS:0000000000000000 > [ 1248.709190] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 1248.710448] CR2: 000055fc6fe1a5b0 CR3: 0000000407f62001 CR4: 00000000001606e0 > [ 1248.711707] Call Trace: > [ 1248.712960] ? do_writepages+0x4b/0xe0 > [ 1248.714201] ? blkdev_readpages+0x20/0x20 > [ 1248.715441] ? do_writepages+0x4b/0xe0 > [ 1248.716684] generic_make_request+0x64/0x400 > [ 1248.717935] ? finish_wait+0x80/0x80 > [ 1248.719181] ? mempool_alloc+0x67/0x1a0 > [ 1248.720425] ? submit_bio+0x6c/0x140 > [ 1248.721663] submit_bio+0x6c/0x140 > [ 1248.722902] submit_bio_wait+0x53/0x80 > [ 1248.724139] blkdev_issue_flush+0x7c/0xb0 > [ 1248.725377] blkdev_fsync+0x2f/0x40 > [ 1248.726612] do_fsync+0x38/0x60 > [ 1248.727849] __x64_sys_fsync+0x10/0x20 > [ 1248.729086] do_syscall_64+0x55/0x110 > [ 1248.730323] entry_SYSCALL_64_after_hwframe+0x44/0xa9 I don't really think it's "btrfs check" causing the problem. Btrfs check, just like all offline tools, uses open_ctree_flags to determine if it's allowed to do write. Without OPEN_CTREE_FLAGS_WRITE, all devices are opened RO, thus any write will just return error without reaching disk. Not to mention such fsync syscall. However the backtrace can't tell which process caused such fsync call. (Maybe LVM user space code?) Thanks, Qu > [ 1248.731565] RIP: 0033:0x7f928354d161 > [ 1248.732805] RSP: 002b:00007ffd35e3f5d8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a > [ 1248.734067] RAX: ffffffffffffffda RBX: 000055fc09c0c260 RCX: 00007f928354d161 > [ 1248.735342] RDX: 000055fc09c13e28 RSI: 000055fc0899f820 RDI: 0000000000000004 > [ 1248.736614] RBP: 000055fc09c0c2d0 R08: 0000000000000005 R09: 000055fc09c0da70 > [ 1248.738001] R10: 000000000000009e R11: 0000000000000246 R12: 0000000000000000 > [ 1248.739272] R13: 000055fc0899d213 R14: 000055fc09c0c290 R15: 0000000000000001 > [ 1248.740542] Code: 24 54 03 00 00 48 8d 74 24 08 48 89 df c6 05 3e 03 d9 00 01 e8 d5 63 01 00 44 89 e2 48 89 c6 48 c7 c7 80 e1 e6 ad e8 a3 4e d1 ff <0f> 0b 4c 8b 63 08 e9 7b fc ff ff 80 3d 15 03 d9 00 00 0f 85 94 > [ 1248.741909] ---[ end trace c2f580dbd579028c ]--- > 1 > > Not really sure why btrfs-check apparently tries to write to the device > (I've had set it blockdev --setro). > > > > And with your patch: > # btrfs check --mode=lowmem /dev/mapper/system ; echo $? > checking extents > checking free space cache > checking fs roots > ERROR: errors found in fs roots > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > DEBUG: error before walking while checking fs root 3 ret -694376768 > DEBUG: normal error in walking while checking node 125988438016 fs root > 257 ret 524296 > DEBUG: error in checking fs root 257 ret 524296 > DEBUG: normal error in walking while checking node 230148259840 fs root > 743 ret 524296 > DEBUG: error in checking fs root 743 ret 524296 > DEBUG: error in checking fs roots ret: > found 435924422656 bytes used, error(s) found > total csum bytes: 423418948 > total tree bytes: 2218328064 > total fs tree bytes: 1557168128 > total extent tree bytes: 125894656 > btree space waste bytes: 429599230 > file data blocks allocated: 5193373646848 > referenced 555255164928 > 1 > > Interestingly it doesn't try to write again (or the kernel doesn't just > print another call trace this time). > > > > Cheers, > Chris. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-09-04 9:14 ` Qu Wenruo @ 2018-09-04 11:45 ` Christoph Anton Mitterer 0 siblings, 0 replies; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-09-04 11:45 UTC (permalink / raw) To: Qu Wenruo, Su Yue, Btrfs BTRFS; +Cc: Su Yue On Tue, 2018-09-04 at 17:14 +0800, Qu Wenruo wrote: > However the backtrace can't tell which process caused such fsync > call. > (Maybe LVM user space code?) Well it was just literally before btrfs-check exited... so I blindly guesses... but arguably it could be just some coincidence. LVM tools are installed, but since I no longer use and PVs/LVs/etc. ... I'd doubt they'd do anything here. Cheers, Chris. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-09-03 20:24 ` Christoph Anton Mitterer 2018-09-04 9:14 ` Qu Wenruo @ 2018-09-05 7:04 ` Su Yue 2018-09-05 12:33 ` Christoph Anton Mitterer 2018-10-18 14:41 ` Christoph Anton Mitterer 1 sibling, 2 replies; 17+ messages in thread From: Su Yue @ 2018-09-05 7:04 UTC (permalink / raw) To: Christoph Anton Mitterer, Btrfs BTRFS; +Cc: Su Yue On 09/04/2018 04:24 AM, Christoph Anton Mitterer wrote: > Hey. > > > On Fri, 2018-08-31 at 10:33 +0800, Su Yue wrote: >> Can you please fetch btrfs-progs from my repo and run lowmem check >> in readonly? >> Repo: https://github.com/Damenly/btrfs-progs/tree/lowmem_debug >> It's based on v4.17.1 plus additonal output for debug only. > > I've adapted your patch to 4.17 from Debian (i.e. not the 4.17.1). > > > First I ran it again with the pristine 4.17 from Debian: > # btrfs check --mode=lowmem /dev/mapper/system ; echo $? > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > checking extents > checking free space cache > checking fs roots > ERROR: errors found in fs roots > found 435924422656 bytes used, error(s) found > total csum bytes: 423418948 > total tree bytes: 2218328064 > total fs tree bytes: 1557168128 > total extent tree bytes: 125894656 > btree space waste bytes: 429599230 > file data blocks allocated: 5193373646848 > referenced 555255164928 > [ 1248.687628] ------------[ cut here ]------------ > [ 1248.688352] generic_make_request: Trying to write to read-only block-device dm-0 (partno 0) > [ 1248.689127] WARNING: CPU: 3 PID: 933 at /build/linux-LgHyGB/linux-4.17.17/block/blk-core.c:2180 generic_make_request_checks+0x43d/0x610 > [ 1248.689909] Modules linked in: dm_crypt algif_skcipher af_alg dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek intel_rapl snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp i915 iwlwifi btusb coretemp btrtl btbcm uvcvideo kvm_intel snd_hda_intel btintel videobuf2_vmalloc bluetooth snd_hda_codec kvm videobuf2_memops videobuf2_v4l2 videobuf2_common cfg80211 snd_hda_core irqbypass videodev jitterentropy_rng drm_kms_helper crct10dif_pclmul snd_hwdep crc32_pclmul drbg ghash_clmulni_intel intel_cstate snd_pcm ansi_cprng ppdev intel_uncore drm media ecdh_generic iTCO_wdt snd_timer iTCO_vendor_support rtsx_pci_ms crc16 snd intel_rapl_perf memstick joydev mei_me rfkill evdev soundcore sg parport_pc pcspkr serio_raw fujitsu_laptop mei i2c_algo_bit parport shpchp sparse_keymap pcc_cpufreq lpc_ich button > [ 1248.693639] video battery ac ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod uas usb_storage crc32c_intel rtsx_pci_sdmmc mmc_core ahci xhci_pci libahci aesni_intel ehci_pci aes_x86_64 libata crypto_simd xhci_hcd ehci_hcd cryptd glue_helper psmouse i2c_i801 scsi_mod rtsx_pci e1000e usbcore usb_common > [ 1248.696956] CPU: 3 PID: 933 Comm: btrfs Not tainted 4.17.0-3-amd64 #1 Debian 4.17.17-1 > [ 1248.698118] Hardware name: FUJITSU LIFEBOOK E782/FJNB253, BIOS Version 2.11 07/15/2014 > [ 1248.699299] RIP: 0010:generic_make_request_checks+0x43d/0x610 > [ 1248.700495] RSP: 0018:ffffac89827c7d88 EFLAGS: 00010286 > [ 1248.701702] RAX: 0000000000000000 RBX: ffff98f4848a9200 RCX: 0000000000000006 > [ 1248.702930] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff98f49e2d6730 > [ 1248.704170] RBP: ffff98f484f6d460 R08: 000000000000033e R09: 0000000000aaaaaa > [ 1248.705422] R10: ffffac89827c7e60 R11: 00000000ffffffff R12: 0000000000000000 > [ 1248.706675] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 > [ 1248.707928] FS: 00007f92842018c0(0000) GS:ffff98f49e2c0000(0000) knlGS:0000000000000000 > [ 1248.709190] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 1248.710448] CR2: 000055fc6fe1a5b0 CR3: 0000000407f62001 CR4: 00000000001606e0 > [ 1248.711707] Call Trace: > [ 1248.712960] ? do_writepages+0x4b/0xe0 > [ 1248.714201] ? blkdev_readpages+0x20/0x20 > [ 1248.715441] ? do_writepages+0x4b/0xe0 > [ 1248.716684] generic_make_request+0x64/0x400 > [ 1248.717935] ? finish_wait+0x80/0x80 > [ 1248.719181] ? mempool_alloc+0x67/0x1a0 > [ 1248.720425] ? submit_bio+0x6c/0x140 > [ 1248.721663] submit_bio+0x6c/0x140 > [ 1248.722902] submit_bio_wait+0x53/0x80 > [ 1248.724139] blkdev_issue_flush+0x7c/0xb0 > [ 1248.725377] blkdev_fsync+0x2f/0x40 > [ 1248.726612] do_fsync+0x38/0x60 > [ 1248.727849] __x64_sys_fsync+0x10/0x20 > [ 1248.729086] do_syscall_64+0x55/0x110 > [ 1248.730323] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 1248.731565] RIP: 0033:0x7f928354d161 > [ 1248.732805] RSP: 002b:00007ffd35e3f5d8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a > [ 1248.734067] RAX: ffffffffffffffda RBX: 000055fc09c0c260 RCX: 00007f928354d161 > [ 1248.735342] RDX: 000055fc09c13e28 RSI: 000055fc0899f820 RDI: 0000000000000004 > [ 1248.736614] RBP: 000055fc09c0c2d0 R08: 0000000000000005 R09: 000055fc09c0da70 > [ 1248.738001] R10: 000000000000009e R11: 0000000000000246 R12: 0000000000000000 > [ 1248.739272] R13: 000055fc0899d213 R14: 000055fc09c0c290 R15: 0000000000000001 > [ 1248.740542] Code: 24 54 03 00 00 48 8d 74 24 08 48 89 df c6 05 3e 03 d9 00 01 e8 d5 63 01 00 44 89 e2 48 89 c6 48 c7 c7 80 e1 e6 ad e8 a3 4e d1 ff <0f> 0b 4c 8b 63 08 e9 7b fc ff ff 80 3d 15 03 d9 00 00 0f 85 94 > [ 1248.741909] ---[ end trace c2f580dbd579028c ]--- > 1 > > Not really sure why btrfs-check apparently tries to write to the device > (I've had set it blockdev --setro). > > Agreed with Qu, btrfs-check shall not try to do any write. > > And with your patch: > # btrfs check --mode=lowmem /dev/mapper/system ; echo $? > checking extents > checking free space cache > checking fs roots > ERROR: errors found in fs roots > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > DEBUG: error before walking while checking fs root 3 ret -694376768 > DEBUG: normal error in walking while checking node 125988438016 fs root > 257 ret 524296 > DEBUG: error in checking fs root 257 ret 524296 > DEBUG: normal error in walking while checking node 230148259840 fs root > 743 ret 524296 > DEBUG: error in checking fs root 743 ret 524296 > DEBUG: error in checking fs roots ret: > found 435924422656 bytes used, error(s) found > total csum bytes: 423418948 > total tree bytes: 2218328064 > total fs tree bytes: 1557168128 > total extent tree bytes: 125894656 > btree space waste bytes: 429599230 > file data blocks allocated: 5193373646848 > referenced 555255164928 > 1 > I found the errors should blame to something about inode_extref check in lowmem mode. I have writeen three patches to detect and report errors about inode_extref. For your convenience, it's based on v4.17: https://github.com/Damenly/btrfs-progs/tree/ext_ref_v4.17 This repo should report more errors. Because one of those is just Whac-A-Mole, I will make it better and send them later to ML. Thanks, Su > Interestingly it doesn't try to write again (or the kernel doesn't just > print another call trace this time). > > > > Cheers, > Chris. > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-09-05 7:04 ` Su Yue @ 2018-09-05 12:33 ` Christoph Anton Mitterer 2018-09-05 12:43 ` Su Yue 2018-10-18 14:41 ` Christoph Anton Mitterer 1 sibling, 1 reply; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-09-05 12:33 UTC (permalink / raw) To: Su Yue, Btrfs BTRFS; +Cc: Su Yue On Wed, 2018-09-05 at 15:04 +0800, Su Yue wrote: > Agreed with Qu, btrfs-check shall not try to do any write. Well.. it could have been just some coincidence :-) > I found the errors should blame to something about inode_extref check > in lowmem mode. So you mean errors in btrfs-check... and it was a false positive? > I have writeen three patches to detect and report errors about > inode_extref. For your convenience, it's based on v4.17: > https://github.com/Damenly/btrfs-progs/tree/ext_ref_v4.17 I hope I can test them soon.... could take a bit longer as I'm about to head off into vacation. Cheers, Chris. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-09-05 12:33 ` Christoph Anton Mitterer @ 2018-09-05 12:43 ` Su Yue 0 siblings, 0 replies; 17+ messages in thread From: Su Yue @ 2018-09-05 12:43 UTC (permalink / raw) To: Christoph Anton Mitterer, Su Yue, Btrfs BTRFS On 2018/9/5 8:33 PM, Christoph Anton Mitterer wrote: > On Wed, 2018-09-05 at 15:04 +0800, Su Yue wrote: >> Agreed with Qu, btrfs-check shall not try to do any write. > > Well.. it could have been just some coincidence :-) > > >> I found the errors should blame to something about inode_extref check >> in lowmem mode. > > So you mean errors in btrfs-check... and it was a false positive? > Not so perfect original and lowmem mode of btrfs-check are. I need to figure out what is on the actual FS, may a false alert or actual error. > >> I have writeen three patches to detect and report errors about >> inode_extref. For your convenience, it's based on v4.17: >> https://github.com/Damenly/btrfs-progs/tree/ext_ref_v4.17 > > I hope I can test them soon.... could take a bit longer as I'm about to > head off into vacation. > Fine, of course. Enjoy it :) Thanks, Su > > Cheers, > Chris. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-09-05 7:04 ` Su Yue 2018-09-05 12:33 ` Christoph Anton Mitterer @ 2018-10-18 14:41 ` Christoph Anton Mitterer 2018-10-19 1:11 ` Su Yue ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-10-18 14:41 UTC (permalink / raw) To: Su Yue, Btrfs BTRFS; +Cc: Su Yue Hey. So I'm back from a longer vacation and had now the time to try out your patches from below: On Wed, 2018-09-05 at 15:04 +0800, Su Yue wrote: > I found the errors should blame to something about inode_extref check > in lowmem mode. > I have writeen three patches to detect and report errors about > inode_extref. For your convenience, it's based on v4.17: > https://github.com/Damenly/btrfs-progs/tree/ext_ref_v4.17 > > This repo should report more errors. Because one of those is just > Whac-A-Mole, I will make it better and send them later to ML. This is the output it gives: checking extents checking free space cache checking fs roots checking only csum items (without verifying data) checking root refs Checking filesystem on /dev/mapper/system UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c found 617228185600 bytes used, no error found total csum bytes: 600139124 total tree bytes: 2516172800 total fs tree bytes: 1639890944 total extent tree bytes: 156532736 btree space waste bytes: 455772589 file data blocks allocated: 7431727771648 referenced 732073979904 (just a bit strange that the UUID line is not in the beginngin)... but other than that, no longer an error message as it seems) Cheers, Chris. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-10-18 14:41 ` Christoph Anton Mitterer @ 2018-10-19 1:11 ` Su Yue 2018-10-19 1:13 ` Su Yue 2018-10-27 12:15 ` Christoph Anton Mitterer 2 siblings, 0 replies; 17+ messages in thread From: Su Yue @ 2018-10-19 1:11 UTC (permalink / raw) To: Christoph Anton Mitterer, Btrfs BTRFS; +Cc: Su Yue On 10/18/18 10:41 PM, Christoph Anton Mitterer wrote: > Hey. > > So I'm back from a longer vacation and had now the time to try out your > patches from below: > > On Wed, 2018-09-05 at 15:04 +0800, Su Yue wrote: >> I found the errors should blame to something about inode_extref check >> in lowmem mode. >> I have writeen three patches to detect and report errors about >> inode_extref. For your convenience, it's based on v4.17: >> https://github.com/Damenly/btrfs-progs/tree/ext_ref_v4.17 >>My bad, I have sent patches to ML according to my guess but forgot to update above repo. I rebased it to v4.17 and pushed again just now, would you please fetch patches from above repo and try again? Thanks, Su >> This repo should report more errors. Because one of those is just >> Whac-A-Mole, I will make it better and send them later to ML. > > > This is the output it gives: > checking extents > checking free space cache > checking fs roots > checking only csum items (without verifying data) > checking root refs > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > found 617228185600 bytes used, no error found > total csum bytes: 600139124 > total tree bytes: 2516172800 > total fs tree bytes: 1639890944 > total extent tree bytes: 156532736 > btree space waste bytes: 455772589 > file data blocks allocated: 7431727771648 > referenced 732073979904 > > (just a bit strange that the UUID line is not in the beginngin)... but > other than that, no longer an error message as it seems) > > > Cheers, > Chris. > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-10-18 14:41 ` Christoph Anton Mitterer 2018-10-19 1:11 ` Su Yue @ 2018-10-19 1:13 ` Su Yue 2018-10-27 12:15 ` Christoph Anton Mitterer 2 siblings, 0 replies; 17+ messages in thread From: Su Yue @ 2018-10-19 1:13 UTC (permalink / raw) To: Christoph Anton Mitterer, Btrfs BTRFS; +Cc: Su Yue [Bad format in previous reply, send again] On 10/18/18 10:41 PM, Christoph Anton Mitterer wrote: > Hey. > > So I'm back from a longer vacation and had now the time to try out your > patches from below: > > On Wed, 2018-09-05 at 15:04 +0800, Su Yue wrote: >> I found the errors should blame to something about inode_extref check >> in lowmem mode. >> I have writeen three patches to detect and report errors about >> inode_extref. For your convenience, it's based on v4.17: >> https://github.com/Damenly/btrfs-progs/tree/ext_ref_v4.17 >> My bad, I have sent patches to ML according to my guess but forgot to update above repo. I rebased it to v4.17 and pushed again just now, would you please fetch patches from above repo and try again? Thanks, Su >> This repo should report more errors. Because one of those is just >> Whac-A-Mole, I will make it better and send them later to ML. > > > This is the output it gives: > checking extents > checking free space cache > checking fs roots > checking only csum items (without verifying data) > checking root refs > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > found 617228185600 bytes used, no error found > total csum bytes: 600139124 > total tree bytes: 2516172800 > total fs tree bytes: 1639890944 > total extent tree bytes: 156532736 > btree space waste bytes: 455772589 > file data blocks allocated: 7431727771648 > referenced 732073979904 > > (just a bit strange that the UUID line is not in the beginngin)... but > other than that, no longer an error message as it seems) > > > Cheers, > Chris. > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-10-18 14:41 ` Christoph Anton Mitterer 2018-10-19 1:11 ` Su Yue 2018-10-19 1:13 ` Su Yue @ 2018-10-27 12:15 ` Christoph Anton Mitterer 2018-11-02 14:10 ` Christoph Anton Mitterer 2 siblings, 1 reply; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-10-27 12:15 UTC (permalink / raw) To: Su Yue, Btrfs BTRFS; +Cc: Su Yue Hey. Without the last patches on 4.17: checking extents checking free space cache checking fs roots ERROR: errors found in fs roots Checking filesystem on /dev/mapper/system UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c found 619543498752 bytes used, error(s) found total csum bytes: 602382204 total tree bytes: 2534309888 total fs tree bytes: 1652097024 total extent tree bytes: 160432128 btree space waste bytes: 459291608 file data blocks allocated: 7334036647936 referenced 730839187456 With the last patches, on 4.17: checking extents checking free space cache checking fs roots checking only csum items (without verifying data) checking root refs Checking filesystem on /dev/mapper/system UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c found 619543498752 bytes used, no error found total csum bytes: 602382204 total tree bytes: 2534309888 total fs tree bytes: 1652097024 total extent tree bytes: 160432128 btree space waste bytes: 459291608 file data blocks allocated: 7334036647936 referenced 730839187456 Cheers, Chris. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-10-27 12:15 ` Christoph Anton Mitterer @ 2018-11-02 14:10 ` Christoph Anton Mitterer 2018-11-03 1:34 ` Su Yue 0 siblings, 1 reply; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-11-02 14:10 UTC (permalink / raw) To: Su Yue, Btrfs BTRFS; +Cc: Su Yue Hey Su. Anything further I need to do in this matter or can I consider it "solved" and you won't need further testing by my side, but just PR the patches of that branch? :-) Thanks, Chris. On Sat, 2018-10-27 at 14:15 +0200, Christoph Anton Mitterer wrote: > Hey. > > > Without the last patches on 4.17: > > checking extents > checking free space cache > checking fs roots > ERROR: errors found in fs roots > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > found 619543498752 bytes used, error(s) found > total csum bytes: 602382204 > total tree bytes: 2534309888 > total fs tree bytes: 1652097024 > total extent tree bytes: 160432128 > btree space waste bytes: 459291608 > file data blocks allocated: 7334036647936 > referenced 730839187456 > > > With the last patches, on 4.17: > > checking extents > checking free space cache > checking fs roots > checking only csum items (without verifying data) > checking root refs > Checking filesystem on /dev/mapper/system > UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c > found 619543498752 bytes used, no error found > total csum bytes: 602382204 > total tree bytes: 2534309888 > total fs tree bytes: 1652097024 > total extent tree bytes: 160432128 > btree space waste bytes: 459291608 > file data blocks allocated: 7334036647936 > referenced 730839187456 > > > Cheers, > Chris. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-11-02 14:10 ` Christoph Anton Mitterer @ 2018-11-03 1:34 ` Su Yue 2018-11-03 1:38 ` Christoph Anton Mitterer 2018-11-03 9:20 ` Nikolay Borisov 0 siblings, 2 replies; 17+ messages in thread From: Su Yue @ 2018-11-03 1:34 UTC (permalink / raw) To: Christoph Anton Mitterer, Su Yue, Btrfs BTRFS On 2018/11/2 10:10 PM, Christoph Anton Mitterer wrote: > Hey Su. > Sorry for the late reply cause I'm busy at other things. > Anything further I need to do in this matter or can I consider it > "solved" and you won't need further testing by my side, but just PR the > patches of that branch? :-) > I just looked through related codes and found the bug. The patches can fix it. So no need to do more tests. Thanks to your tests and patience. :) In previous output of debug version, we can see @ret code is 524296 which is (DIR_ITEM_MISMATCH(1 << 3) | DIR_INDEX_MISMATCH (1<<19)). In btrfs-progs v4.17, function check_inode_extref() passes u64 @mode as the last parameter of find_dir_item(); However, find_dir_item() is defined as: static int find_dir_item(struct btrfs_root *root, struct btrfs_key *key, struct btrfs_key *location_key, char *name, u32 namelen, u8 file_type); The type of the last argument is u8 not u64. So the case is that while checking files with inode_extrefs, if (imode != file_type), then find_dir_item() thinks it found DIR_ITEM_MISMATCH or DIR_INDEX_MISMATCH. Thanks, Su > Thanks, > Chris. > > On Sat, 2018-10-27 at 14:15 +0200, Christoph Anton Mitterer wrote: >> Hey. >> >> >> Without the last patches on 4.17: >> >> checking extents >> checking free space cache >> checking fs roots >> ERROR: errors found in fs roots >> Checking filesystem on /dev/mapper/system >> UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c >> found 619543498752 bytes used, error(s) found >> total csum bytes: 602382204 >> total tree bytes: 2534309888 >> total fs tree bytes: 1652097024 >> total extent tree bytes: 160432128 >> btree space waste bytes: 459291608 >> file data blocks allocated: 7334036647936 >> referenced 730839187456 >> >> >> With the last patches, on 4.17: >> >> checking extents >> checking free space cache >> checking fs roots >> checking only csum items (without verifying data) >> checking root refs >> Checking filesystem on /dev/mapper/system >> UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c >> found 619543498752 bytes used, no error found >> total csum bytes: 602382204 >> total tree bytes: 2534309888 >> total fs tree bytes: 1652097024 >> total extent tree bytes: 160432128 >> btree space waste bytes: 459291608 >> file data blocks allocated: 7334036647936 >> referenced 730839187456 >> >> >> Cheers, >> Chris. >> > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-11-03 1:34 ` Su Yue @ 2018-11-03 1:38 ` Christoph Anton Mitterer 2018-11-03 9:20 ` Nikolay Borisov 1 sibling, 0 replies; 17+ messages in thread From: Christoph Anton Mitterer @ 2018-11-03 1:38 UTC (permalink / raw) To: Su Yue, Su Yue, Btrfs BTRFS On Sat, 2018-11-03 at 09:34 +0800, Su Yue wrote: > Sorry for the late reply cause I'm busy at other things. No worries :-) > I just looked through related codes and found the bug. > The patches can fix it. So no need to do more tests. > Thanks to your tests and patience. :) Thanks for fixing :-) Best wishes, Chris. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-11-03 1:34 ` Su Yue 2018-11-03 1:38 ` Christoph Anton Mitterer @ 2018-11-03 9:20 ` Nikolay Borisov 2018-11-05 1:21 ` Su Yue 1 sibling, 1 reply; 17+ messages in thread From: Nikolay Borisov @ 2018-11-03 9:20 UTC (permalink / raw) To: Christoph Anton Mitterer, Su Yue, Btrfs BTRFS On 3.11.18 г. 3:34 ч., Su Yue wrote: > > > On 2018/11/2 10:10 PM, Christoph Anton Mitterer wrote: >> Hey Su. >> > > Sorry for the late reply cause I'm busy at other things. > >> Anything further I need to do in this matter or can I consider it >> "solved" and you won't need further testing by my side, but just PR the >> patches of that branch? :-) >> > > I just looked through related codes and found the bug. > The patches can fix it. So no need to do more tests. > Thanks to your tests and patience. :) > > > In previous output of debug version, we can see @ret code > is 524296 which is (DIR_ITEM_MISMATCH(1 << 3) | DIR_INDEX_MISMATCH > (1<<19)). > > In btrfs-progs v4.17, > function check_inode_extref() passes u64 @mode as the last parameter > of find_dir_item(); > However, find_dir_item() is defined as: > static int find_dir_item(struct btrfs_root *root, struct btrfs_key *key, > struct btrfs_key *location_key, char *name, > u32 namelen, u8 file_type); > > The type of the last argument is u8 not u64. So this would have been caught by gcc's -Wconversion, except it likely wouldn't have been because right now this option produces loads of false positives... Too bad... > > So the case is that while checking files with inode_extrefs, > if (imode != file_type), then find_dir_item() thinks it found > DIR_ITEM_MISMATCH or DIR_INDEX_MISMATCH. > > Thanks, > Su > >> Thanks, >> Chris. >> >> On Sat, 2018-10-27 at 14:15 +0200, Christoph Anton Mitterer wrote: >>> Hey. >>> >>> >>> Without the last patches on 4.17: >>> >>> checking extents >>> checking free space cache >>> checking fs roots >>> ERROR: errors found in fs roots >>> Checking filesystem on /dev/mapper/system >>> UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c >>> found 619543498752 bytes used, error(s) found >>> total csum bytes: 602382204 >>> total tree bytes: 2534309888 >>> total fs tree bytes: 1652097024 >>> total extent tree bytes: 160432128 >>> btree space waste bytes: 459291608 >>> file data blocks allocated: 7334036647936 >>> referenced 730839187456 >>> >>> >>> With the last patches, on 4.17: >>> >>> checking extents >>> checking free space cache >>> checking fs roots >>> checking only csum items (without verifying data) >>> checking root refs >>> Checking filesystem on /dev/mapper/system >>> UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c >>> found 619543498752 bytes used, no error found >>> total csum bytes: 602382204 >>> total tree bytes: 2534309888 >>> total fs tree bytes: 1652097024 >>> total extent tree bytes: 160432128 >>> btree space waste bytes: 459291608 >>> file data blocks allocated: 7334036647936 >>> referenced 730839187456 >>> >>> >>> Cheers, >>> Chris. >>> >> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: fsck lowmem mode only: ERROR: errors found in fs roots 2018-11-03 9:20 ` Nikolay Borisov @ 2018-11-05 1:21 ` Su Yue 0 siblings, 0 replies; 17+ messages in thread From: Su Yue @ 2018-11-05 1:21 UTC (permalink / raw) To: Nikolay Borisov, Christoph Anton Mitterer, Btrfs BTRFS On 11/3/18 5:20 PM, Nikolay Borisov wrote: > > > On 3.11.18 г. 3:34 ч., Su Yue wrote: >> >> >> On 2018/11/2 10:10 PM, Christoph Anton Mitterer wrote: >>> Hey Su. >>> >> >> Sorry for the late reply cause I'm busy at other things. >> >>> Anything further I need to do in this matter or can I consider it >>> "solved" and you won't need further testing by my side, but just PR the >>> patches of that branch? :-) >>> >> >> I just looked through related codes and found the bug. >> The patches can fix it. So no need to do more tests. >> Thanks to your tests and patience. :) >> >> >> In previous output of debug version, we can see @ret code >> is 524296 which is (DIR_ITEM_MISMATCH(1 << 3) | DIR_INDEX_MISMATCH >> (1<<19)). >> >> In btrfs-progs v4.17, >> function check_inode_extref() passes u64 @mode as the last parameter >> of find_dir_item(); >> However, find_dir_item() is defined as: >> static int find_dir_item(struct btrfs_root *root, struct btrfs_key *key, >> struct btrfs_key *location_key, char *name, >> u32 namelen, u8 file_type); >> >> The type of the last argument is u8 not u64. > > So this would have been caught by gcc's -Wconversion, except it likely > wouldn't have been because right now this option produces loads of false > positives... Too bad... > Yes, type cast is too common in C, enabling such compile warnings is annoying... >> >> So the case is that while checking files with inode_extrefs, >> if (imode != file_type), then find_dir_item() thinks it found >> DIR_ITEM_MISMATCH or DIR_INDEX_MISMATCH. >> >> Thanks, >> Su >> >>> Thanks, >>> Chris. >>> >>> On Sat, 2018-10-27 at 14:15 +0200, Christoph Anton Mitterer wrote: >>>> Hey. >>>> >>>> >>>> Without the last patches on 4.17: >>>> >>>> checking extents >>>> checking free space cache >>>> checking fs roots >>>> ERROR: errors found in fs roots >>>> Checking filesystem on /dev/mapper/system >>>> UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c >>>> found 619543498752 bytes used, error(s) found >>>> total csum bytes: 602382204 >>>> total tree bytes: 2534309888 >>>> total fs tree bytes: 1652097024 >>>> total extent tree bytes: 160432128 >>>> btree space waste bytes: 459291608 >>>> file data blocks allocated: 7334036647936 >>>> referenced 730839187456 >>>> >>>> >>>> With the last patches, on 4.17: >>>> >>>> checking extents >>>> checking free space cache >>>> checking fs roots >>>> checking only csum items (without verifying data) >>>> checking root refs >>>> Checking filesystem on /dev/mapper/system >>>> UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c >>>> found 619543498752 bytes used, no error found >>>> total csum bytes: 602382204 >>>> total tree bytes: 2534309888 >>>> total fs tree bytes: 1652097024 >>>> total extent tree bytes: 160432128 >>>> btree space waste bytes: 459291608 >>>> file data blocks allocated: 7334036647936 >>>> referenced 730839187456 >>>> >>>> >>>> Cheers, >>>> Chris. >>>> >>> > > ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-11-05 1:13 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-30 16:47 fsck lowmem mode only: ERROR: errors found in fs roots Christoph Anton Mitterer 2018-08-31 2:33 ` Su Yue 2018-09-03 20:24 ` Christoph Anton Mitterer 2018-09-04 9:14 ` Qu Wenruo 2018-09-04 11:45 ` Christoph Anton Mitterer 2018-09-05 7:04 ` Su Yue 2018-09-05 12:33 ` Christoph Anton Mitterer 2018-09-05 12:43 ` Su Yue 2018-10-18 14:41 ` Christoph Anton Mitterer 2018-10-19 1:11 ` Su Yue 2018-10-19 1:13 ` Su Yue 2018-10-27 12:15 ` Christoph Anton Mitterer 2018-11-02 14:10 ` Christoph Anton Mitterer 2018-11-03 1:34 ` Su Yue 2018-11-03 1:38 ` Christoph Anton Mitterer 2018-11-03 9:20 ` Nikolay Borisov 2018-11-05 1:21 ` Su Yue
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.