All of lore.kernel.org
 help / color / mirror / Atom feed
* How to recover a filesystem without formatting nor using the btrfs check command.
@ 2016-10-23 19:42 none
  2016-10-24  1:15 ` Qu Wenruo
  0 siblings, 1 reply; 11+ messages in thread
From: none @ 2016-10-23 19:42 UTC (permalink / raw)
  To: linux-btrfs

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

Hello,
I have the following bug 
https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, is 
there a way to recover my filesystem in clean state without formatting 
or using btrsfck ? Of course, the point is no longer need the files 
which are damaged.
So is there a way to recover a btrfs filesystem by deleting the 
corrupted data instead of trying to restore it ?

btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
Data, single: total=66.01GiB, used=0.00B
System, DUP: total=8.00MiB, used=16.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=5.00GiB, used=28.00KiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=4.00MiB, used=0.00B

btrfs progs version 4.7.3 from Devuan

Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
         Total devices 1 FS bytes used 44.00KiB
         devid    1 size 298.91GiB used 76.04GiB path 
/dev/mapper/isw_bdffeeeijj_Volume0p7

uname -a
Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1 
(2016-04-20) x86_64 GNU/Linux

Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 : 
https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz

Thanks,

[-- Attachment #2: kernel backtrace on deletion.log --]
[-- Type: text/plain, Size: 24173 bytes --]

[120173.931922] BTRFS info (device dm-7): force zlib compression
[120173.935145] BTRFS info (device dm-7): force clearing of disk cache
[120173.935152] BTRFS info (device dm-7): enabling auto defrag
[120173.935157] BTRFS info (device dm-7): turning on discard
[120173.935162] BTRFS info (device dm-7): enabling inode map caching
[120173.935167] BTRFS info (device dm-7): enabling auto recovery
[120173.935187] BTRFS info (device dm-7): disk space caching is enabled
[120174.038539] BTRFS: checking UUID tree
[120180.620022] ------------[ cut here ]------------
[120180.623489] WARNING: CPU: 0 PID: 406 at /build/linux-Ki7dwx/linux-4.5.1/fs/btrfs/extent-tree.c:6593 __btrfs_free_extent.isra.68+0x6e5/0xdc0 [btrfs]()
[120180.627060] Modules linked in: loop(E) cmac(E) ecb(E) rfcomm(E) ctr(E) ccm(E) cpufreq_userspace(E) cpufreq_stats(E) cpufreq_conservative(E) cpufreq_powersave(E) bnep(E) binfmt_misc(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) nfs(E) lockd(E) grace(E) fscache(E) sunrpc(E) lp(E) btrfs(E) crc32c_generic(E) hid_generic(E) btusb(E) btrtl(E) intel_rapl(E) ppdev(E) arc4(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) iwlmvm(E) mac80211(E) irqbypass(E) hci_uart(E) btbcm(E) iwlwifi(E) btqca(E) btintel(E) bluetooth(E) cfg80211(E) intel_lpss_acpi(E) efi_pstore(E) thermal(E) serio_raw(E) crct10dif_pclmul(E) pcspkr(E) efivars(E) sr_mod(E) cdrom(E) rfkill(E) intel_lpss(E) sg(E) parport_pc(E) fan(E) battery(E) parport(E) mfd_core(E) 8250_fintek(E) evdev(E) acpi_als(E) i2c_i801(E) kfifo_buf(E) fjes(E) i2c_hid(E)
[120180.633590]  processor(E) acpi_pad(E) shpchp(E) mei_me(E) mei(E) tpm_crb(E) tpm_tis(E) tpm(E) industrialio(E) wmi(E) xhci_pci(E) xhci_hcd(E) dm_mirror(E) dm_region_hash(E) dm_log(E) sha512_ssse3(E) sha512_generic(E) sha256_ssse3(E) sha1_ssse3(E) dm_raid(E) dm_mod(E) raid456(E) async_raid6_recov(E) md_mod(E) async_pq(E) libcrc32c(E) raid6_pq(E) async_memcpy(E) async_xor(E) async_tx(E) snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) xor(E) zsmalloc(E) nls_utf8(E) hid_magicmouse(E) usbhid(E) hid(E) usbcore(E) usb_common(E) snd_hda_intel(E) snd_hda_codec(E) snd_hwdep(E) snd_hda_core(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) ghash_clmulni_intel(E) jitterentropy_rng(E) hmac(E) drbg(E) ansi_cprng(E) aesni_intel(E) glue_helper(E) aes_x86_64(E) lrw(E) gf128mul(E) ablk_helper(E)
[120180.636782]  cryptd(E) ahci(E) libahci(E) libata(E) sd_mod(E) scsi_mod(E) uinput(E) x86_pkg_temp_thermal(E) crc32c_intel(E) crc32_pclmul(E) ext4(E) mbcache(E) jbd2(E) crc16(E) i915(E) drm_kms_helper(E) drm(E) video(E) button(E) i2c_algo_bit(E)
[120180.638349] CPU: 0 PID: 406 Comm: kworker/u16:0 Tainted: G        W   E   4.5.0-0.bpo.1-amd64 #1 Debian 4.5.1-1~bpo8+1
[120180.639154] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z170-HD3P-CF, BIOS F5i 01/15/2016
[120180.639969] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
[120180.640770]  0000000000000286 00000000a23c6b5f ffffffff813099f5 0000000000000000
[120180.641564]  ffffffffc0ae3068 ffffffff81079a61 000000002871a000 00000000fffffffe
[120180.642397]  ffff880209457000 ffff8801ad69c000 0000000000000000 ffffffffc0a40b55
[120180.643293] Call Trace:
[120180.644096]  [<ffffffff813099f5>] ? dump_stack+0x5c/0x77
[120180.644903]  [<ffffffff81079a61>] ? warn_slowpath_common+0x81/0xb0
[120180.645707]  [<ffffffffc0a40b55>] ? __btrfs_free_extent.isra.68+0x6e5/0xdc0 [btrfs]
[120180.646511]  [<ffffffffc0aa98d9>] ? btrfs_merge_delayed_refs+0x69/0x600 [btrfs]
[120180.647302]  [<ffffffffc0a4509d>] ? __btrfs_run_delayed_refs+0x9ad/0x1210 [btrfs]
[120180.648317]  [<ffffffff811cb7f0>] ? kmem_cache_alloc+0x360/0x4e0
[120180.649382]  [<ffffffffc0a4864e>] ? btrfs_run_delayed_refs+0x8e/0x2b0 [btrfs]
[120180.650182]  [<ffffffffc0a488a2>] ? delayed_ref_async_start+0x32/0x80 [btrfs]
[120180.651013]  [<ffffffffc0a8fe36>] ? normal_work_helper+0xc6/0x2c0 [btrfs]
[120180.652083]  [<ffffffff81091c58>] ? process_one_work+0x148/0x400
[120180.652888]  [<ffffffff81092705>] ? worker_thread+0x65/0x4a0
[120180.653673]  [<ffffffff810926a0>] ? rescuer_thread+0x340/0x340
[120180.654512]  [<ffffffff810979ef>] ? kthread+0xdf/0x100
[120180.655363]  [<ffffffff81097910>] ? kthread_park+0x50/0x50
[120180.656118]  [<ffffffff815b9b5f>] ? ret_from_fork+0x3f/0x70
[120180.656880]  [<ffffffff81097910>] ? kthread_park+0x50/0x50
[120180.657634] ---[ end trace daf84f8012a6f01d ]---
[120180.658389] BTRFS info (device dm-7): leaf 76265070592 total ptrs 43 free space 1780
[120180.658390] 	item 0 key (0 192 4194304) itemoff 3971 itemsize 24
[120180.658391] 		block group used 0
[120180.658391] 	item 1 key (4194304 192 8388608) itemoff 3947 itemsize 24
[120180.658392] 		block group used 0
[120180.658392] 	item 2 key (12582912 192 8388608) itemoff 3923 itemsize 24
[120180.658393] 		block group used 0
[120180.658393] 	item 3 key (20971520 168 4096) itemoff 3872 itemsize 51
[120180.658394] 		extent refs 1 gen 3555360 flags 2
[120180.658394] 		tree block key (1 216 1) level 0
[120180.658395] 		tree block backref root 3
[120180.658395] 	item 4 key (20971520 192 8388608) itemoff 3848 itemsize 24
[120180.658396] 		block group used 16384
[120180.658396] 	item 5 key (20975616 168 4096) itemoff 3797 itemsize 51
[120180.658397] 		extent refs 1 gen 3555360 flags 2
[120180.658397] 		tree block key (1 216 1) level 1
[120180.658397] 		tree block backref root 3
[120180.658398] 	item 6 key (20979712 168 4096) itemoff 3746 itemsize 51
[120180.658398] 		extent refs 1 gen 3555360 flags 2
[120180.658399] 		tree block key (256 228 15061745664) level 0
[120180.658399] 		tree block backref root 3
[120180.658400] 	item 7 key (20983808 168 4096) itemoff 3695 itemsize 51
[120180.658400] 		extent refs 1 gen 3555360 flags 2
[120180.658401] 		tree block key (256 228 76265029632) level 0
[120180.658401] 		tree block backref root 3
[120180.658401] 	item 8 key (29360128 192 1073741824) itemoff 3671 itemsize 24
[120180.658402] 		block group used 0
[120180.658402] 	item 9 key (1103101952 192 1073741824) itemoff 3647 itemsize 24
[120180.658403] 		block group used 0
[120180.658403] 	item 10 key (2176843776 192 1073741824) itemoff 3623 itemsize 24
[120180.658404] 		block group used 0
[120180.658404] 	item 11 key (3250585600 192 1073741824) itemoff 3599 itemsize 24
[120180.658405] 		block group used 0
[120180.658405] 	item 12 key (4324327424 192 1073741824) itemoff 3575 itemsize 24
[120180.658405] 		block group used 0
[120180.658406] 	item 13 key (5398069248 192 1073741824) itemoff 3551 itemsize 24
[120180.658406] 		block group used 0
[120180.658407] 	item 14 key (6471811072 192 1073741824) itemoff 3527 itemsize 24
[120180.658407] 		block group used 0
[120180.658408] 	item 15 key (7545552896 192 1073741824) itemoff 3503 itemsize 24
[120180.658408] 		block group used 0
[120180.658409] 	item 16 key (8619294720 192 1073741824) itemoff 3479 itemsize 24
[120180.658409] 		block group used 0
[120180.658409] 	item 17 key (9693036544 192 1073741824) itemoff 3455 itemsize 24
[120180.658410] 		block group used 0
[120180.658410] 	item 18 key (10766778368 192 1073741824) itemoff 3431 itemsize 24
[120180.658411] 		block group used 0
[120180.658411] 	item 19 key (11840520192 192 1073741824) itemoff 3407 itemsize 24
[120180.658412] 		block group used 0
[120180.658412] 	item 20 key (12914262016 192 1073741824) itemoff 3383 itemsize 24
[120180.658412] 		block group used 0
[120180.658413] 	item 21 key (13988003840 192 1073741824) itemoff 3359 itemsize 24
[120180.658413] 		block group used 0
[120180.658414] 	item 22 key (15061745664 192 1073741824) itemoff 3335 itemsize 24
[120180.658414] 		block group used 0
[120180.658415] 	item 23 key (16135487488 192 1073741824) itemoff 3311 itemsize 24
[120180.658415] 		block group used 0
[120180.658416] 	item 24 key (17209229312 192 1073741824) itemoff 3287 itemsize 24
[120180.658416] 		block group used 0
[120180.658416] 	item 25 key (18282971136 192 1073741824) itemoff 3263 itemsize 24
[120180.658417] 		block group used 0
[120180.658417] 	item 26 key (19356712960 192 1073741824) itemoff 3239 itemsize 24
[120180.658418] 		block group used 0
[120180.658418] 	item 27 key (20430454784 192 1073741824) itemoff 3215 itemsize 24
[120180.658419] 		block group used 0
[120180.658419] 	item 28 key (21504196608 192 1073741824) itemoff 3191 itemsize 24
[120180.658419] 		block group used 0
[120180.658420] 	item 29 key (22577938432 192 1073741824) itemoff 3167 itemsize 24
[120180.658420] 		block group used 0
[120180.658421] 	item 30 key (23651680256 192 1073741824) itemoff 3143 itemsize 24
[120180.658421] 		block group used 0
[120180.658422] 	item 31 key (24725422080 192 1073741824) itemoff 3119 itemsize 24
[120180.658422] 		block group used 0
[120180.658423] 	item 32 key (25799163904 192 1073741824) itemoff 3095 itemsize 24
[120180.658423] 		block group used 0
[120180.658423] 	item 33 key (26872905728 192 1073741824) itemoff 3071 itemsize 24
[120180.658424] 		block group used 0
[120180.658424] 	item 34 key (27946647552 192 1073741824) itemoff 3047 itemsize 24
[120180.658425] 		block group used 0
[120180.658425] 	item 35 key (29020389376 192 1073741824) itemoff 3023 itemsize 24
[120180.658425] 		block group used 0
[120180.658426] 	item 36 key (30094131200 192 1073741824) itemoff 2999 itemsize 24
[120180.658426] 		block group used 0
[120180.658427] 	item 37 key (31167873024 192 1073741824) itemoff 2975 itemsize 24
[120180.658427] 		block group used 0
[120180.658428] 	item 38 key (32241614848 192 1073741824) itemoff 2951 itemsize 24
[120180.658428] 		block group used 0
[120180.658429] 	item 39 key (33315356672 192 1073741824) itemoff 2927 itemsize 24
[120180.658429] 		block group used 0
[120180.658429] 	item 40 key (37610323968 192 1073741824) itemoff 2903 itemsize 24
[120180.658430] 		block group used 0
[120180.658430] 	item 41 key (38684065792 192 1073741824) itemoff 2879 itemsize 24
[120180.658431] 		block group used 0
[120180.658431] 	item 42 key (39757807616 192 1073741824) itemoff 2855 itemsize 24
[120180.658431] 		block group used 0
[120180.658432] BTRFS error (device dm-7): unable to find ref byte nr 678535168 parent 0 root 5  owner 2 offset 0
[120180.659178] ------------[ cut here ]------------
[120180.659941] WARNING: CPU: 0 PID: 406 at /build/linux-Ki7dwx/linux-4.5.1/fs/btrfs/extent-tree.c:6599 __btrfs_free_extent.isra.68+0x752/0xdc0 [btrfs]()
[120180.660709] BTRFS: Transaction aborted (error -2)
[120180.660710] Modules linked in: loop(E) cmac(E) ecb(E) rfcomm(E) ctr(E) ccm(E) cpufreq_userspace(E) cpufreq_stats(E) cpufreq_conservative(E) cpufreq_powersave(E) bnep(E) binfmt_misc(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) nfs(E) lockd(E) grace(E) fscache(E) sunrpc(E) lp(E) btrfs(E) crc32c_generic(E) hid_generic(E) btusb(E) btrtl(E) intel_rapl(E) ppdev(E) arc4(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) iwlmvm(E) mac80211(E) irqbypass(E) hci_uart(E) btbcm(E) iwlwifi(E) btqca(E) btintel(E) bluetooth(E) cfg80211(E) intel_lpss_acpi(E) efi_pstore(E) thermal(E) serio_raw(E) crct10dif_pclmul(E) pcspkr(E) efivars(E) sr_mod(E) cdrom(E) rfkill(E) intel_lpss(E) sg(E) parport_pc(E) fan(E) battery(E) parport(E) mfd_core(E) 8250_fintek(E) evdev(E) acpi_als(E) i2c_i801(E) kfifo_buf(E) fjes(E) i2c_hid(E)
[120180.663236]  processor(E) acpi_pad(E) shpchp(E) mei_me(E) mei(E) tpm_crb(E) tpm_tis(E) tpm(E) industrialio(E) wmi(E) xhci_pci(E) xhci_hcd(E) dm_mirror(E) dm_region_hash(E) dm_log(E) sha512_ssse3(E) sha512_generic(E) sha256_ssse3(E) sha1_ssse3(E) dm_raid(E) dm_mod(E) raid456(E) async_raid6_recov(E) md_mod(E) async_pq(E) libcrc32c(E) raid6_pq(E) async_memcpy(E) async_xor(E) async_tx(E) snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) xor(E) zsmalloc(E) nls_utf8(E) hid_magicmouse(E) usbhid(E) hid(E) usbcore(E) usb_common(E) snd_hda_intel(E) snd_hda_codec(E) snd_hwdep(E) snd_hda_core(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) ghash_clmulni_intel(E) jitterentropy_rng(E) hmac(E) drbg(E) ansi_cprng(E) aesni_intel(E) glue_helper(E) aes_x86_64(E) lrw(E) gf128mul(E) ablk_helper(E)
[120180.667105]  cryptd(E) ahci(E) libahci(E) libata(E) sd_mod(E) scsi_mod(E) uinput(E) x86_pkg_temp_thermal(E) crc32c_intel(E) crc32_pclmul(E) ext4(E) mbcache(E) jbd2(E) crc16(E) i915(E) drm_kms_helper(E) drm(E) video(E) button(E) i2c_algo_bit(E)
[120180.669116] CPU: 0 PID: 406 Comm: kworker/u16:0 Tainted: G        W   E   4.5.0-0.bpo.1-amd64 #1 Debian 4.5.1-1~bpo8+1
[120180.670340] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z170-HD3P-CF, BIOS F5i 01/15/2016
[120180.671273] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
[120180.672208]  0000000000000286 00000000a23c6b5f ffffffff813099f5 ffff880017b77b18
[120180.673151]  ffffffffc0ae3068 ffffffff81079a61 000000002871a000 ffff880017b77b70
[120180.674323]  ffff880209457000 ffff8801ad69c000 0000000000000000 ffffffff81079aec
[120180.675254] Call Trace:
[120180.676182]  [<ffffffff813099f5>] ? dump_stack+0x5c/0x77
[120180.677122]  [<ffffffff81079a61>] ? warn_slowpath_common+0x81/0xb0
[120180.678060]  [<ffffffff81079aec>] ? warn_slowpath_fmt+0x5c/0x80
[120180.678961]  [<ffffffffc0a40bc2>] ? __btrfs_free_extent.isra.68+0x752/0xdc0 [btrfs]
[120180.679855]  [<ffffffffc0aa98d9>] ? btrfs_merge_delayed_refs+0x69/0x600 [btrfs]
[120180.680750]  [<ffffffffc0a4509d>] ? __btrfs_run_delayed_refs+0x9ad/0x1210 [btrfs]
[120180.681618]  [<ffffffff811cb7f0>] ? kmem_cache_alloc+0x360/0x4e0
[120180.682502]  [<ffffffffc0a4864e>] ? btrfs_run_delayed_refs+0x8e/0x2b0 [btrfs]
[120180.683723]  [<ffffffffc0a488a2>] ? delayed_ref_async_start+0x32/0x80 [btrfs]
[120180.684583]  [<ffffffffc0a8fe36>] ? normal_work_helper+0xc6/0x2c0 [btrfs]
[120180.685417]  [<ffffffff81091c58>] ? process_one_work+0x148/0x400
[120180.686242]  [<ffffffff81092705>] ? worker_thread+0x65/0x4a0
[120180.687059]  [<ffffffff810926a0>] ? rescuer_thread+0x340/0x340
[120180.688142]  [<ffffffff810979ef>] ? kthread+0xdf/0x100
[120180.688915]  [<ffffffff81097910>] ? kthread_park+0x50/0x50
[120180.689930]  [<ffffffff815b9b5f>] ? ret_from_fork+0x3f/0x70
[120180.690980]  [<ffffffff81097910>] ? kthread_park+0x50/0x50
[120180.691801] ---[ end trace daf84f8012a6f01e ]---
[120180.692488] BTRFS: error (device dm-7) in __btrfs_free_extent:6599: errno=-2 No such entry
[120180.693179] BTRFS info (device dm-7): forced readonly
[120180.693181] BTRFS: error (device dm-7) in btrfs_run_delayed_refs:2946: errno=-2 No such entry
[120180.693182] ------------[ cut here ]------------
[120180.693188] WARNING: CPU: 3 PID: 798 at /build/linux-Ki7dwx/linux-4.5.1/fs/btrfs/extent-tree.c:6593 __btrfs_free_extent.isra.68+0x6e5/0xdc0 [btrfs]()
[120180.693196] Modules linked in: loop(E) cmac(E) ecb(E) rfcomm(E) ctr(E) ccm(E) cpufreq_userspace(E) cpufreq_stats(E) cpufreq_conservative(E) cpufreq_powersave(E) bnep(E) binfmt_misc(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) nfs(E) lockd(E) grace(E) fscache(E) sunrpc(E) lp(E) btrfs(E) crc32c_generic(E) hid_generic(E) btusb(E) btrtl(E) intel_rapl(E) ppdev(E) arc4(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) iwlmvm(E) mac80211(E) irqbypass(E) hci_uart(E) btbcm(E) iwlwifi(E) btqca(E) btintel(E) bluetooth(E) cfg80211(E) intel_lpss_acpi(E) efi_pstore(E) thermal(E) serio_raw(E) crct10dif_pclmul(E) pcspkr(E) efivars(E) sr_mod(E) cdrom(E) rfkill(E) intel_lpss(E) sg(E) parport_pc(E) fan(E) battery(E) parport(E) mfd_core(E) 8250_fintek(E) evdev(E) acpi_als(E) i2c_i801(E) kfifo_buf(E) fjes(E) i2c_hid(E)
[120180.693203]  processor(E) acpi_pad(E) shpchp(E) mei_me(E) mei(E) tpm_crb(E) tpm_tis(E) tpm(E) industrialio(E) wmi(E) xhci_pci(E) xhci_hcd(E) dm_mirror(E) dm_region_hash(E) dm_log(E) sha512_ssse3(E) sha512_generic(E) sha256_ssse3(E) sha1_ssse3(E) dm_raid(E) dm_mod(E) raid456(E) async_raid6_recov(E) md_mod(E) async_pq(E) libcrc32c(E) raid6_pq(E) async_memcpy(E) async_xor(E) async_tx(E) snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) xor(E) zsmalloc(E) nls_utf8(E) hid_magicmouse(E) usbhid(E) hid(E) usbcore(E) usb_common(E) snd_hda_intel(E) snd_hda_codec(E) snd_hwdep(E) snd_hda_core(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) ghash_clmulni_intel(E) jitterentropy_rng(E) hmac(E) drbg(E) ansi_cprng(E) aesni_intel(E) glue_helper(E) aes_x86_64(E) lrw(E) gf128mul(E) ablk_helper(E)
[120180.693206]  cryptd(E) ahci(E) libahci(E) libata(E) sd_mod(E) scsi_mod(E) uinput(E) x86_pkg_temp_thermal(E) crc32c_intel(E) crc32_pclmul(E) ext4(E) mbcache(E) jbd2(E) crc16(E) i915(E) drm_kms_helper(E) drm(E) video(E) button(E) i2c_algo_bit(E)
[120180.693206] CPU: 3 PID: 798 Comm: rm Tainted: G        W   E   4.5.0-0.bpo.1-amd64 #1 Debian 4.5.1-1~bpo8+1
[120180.693207] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Z170-HD3P-CF, BIOS F5i 01/15/2016
[120180.693208]  0000000000000286 00000000c35d6d77 ffffffff813099f5 0000000000000000
[120180.693208]  ffffffffc0ae3068 ffffffff81079a61 000000002ecff000 00000000fffffffe
[120180.693209]  ffff880209457000 ffff8801ad69c000 0000000000000000 ffffffffc0a40b55
[120180.693209] Call Trace:
[120180.693210]  [<ffffffff813099f5>] ? dump_stack+0x5c/0x77
[120180.693211]  [<ffffffff81079a61>] ? warn_slowpath_common+0x81/0xb0
[120180.693217]  [<ffffffffc0a40b55>] ? __btrfs_free_extent.isra.68+0x6e5/0xdc0 [btrfs]
[120180.693219]  [<ffffffff81177ff4>] ? __set_page_dirty_nobuffers+0xe4/0x150
[120180.693226]  [<ffffffffc0aa98d9>] ? btrfs_merge_delayed_refs+0x69/0x600 [btrfs]
[120180.693231]  [<ffffffffc0a4509d>] ? __btrfs_run_delayed_refs+0x9ad/0x1210 [btrfs]
[120180.693238]  [<ffffffffc0a82124>] ? set_extent_buffer_dirty+0x64/0xb0 [btrfs]
[120180.693244]  [<ffffffffc0a57a96>] ? btrfs_mark_buffer_dirty+0x86/0xc0 [btrfs]
[120180.693249]  [<ffffffffc0a4864e>] ? btrfs_run_delayed_refs+0x8e/0x2b0 [btrfs]
[120180.693255]  [<ffffffffc0a68e27>] ? btrfs_truncate_inode_items+0x627/0xde0 [btrfs]
[120180.693261]  [<ffffffffc0a6a595>] ? btrfs_evict_inode+0x495/0x5f0 [btrfs]
[120180.693262]  [<ffffffff81205e36>] ? evict+0xb6/0x180
[120180.693264]  [<ffffffff811faf38>] ? do_unlinkat+0x148/0x300
[120180.693265]  [<ffffffff815b97b6>] ? system_call_fast_compare_end+0xc/0x6b
[120180.693266] ---[ end trace daf84f8012a6f01f ]---
[120180.693267] BTRFS info (device dm-7): leaf 76265070592 total ptrs 43 free space 1780
[120180.693268] 	item 0 key (0 192 4194304) itemoff 3971 itemsize 24
[120180.693268] 		block group used 0
[120180.693269] 	item 1 key (4194304 192 8388608) itemoff 3947 itemsize 24
[120180.693269] 		block group used 0
[120180.693270] 	item 2 key (12582912 192 8388608) itemoff 3923 itemsize 24
[120180.693270] 		block group used 0
[120180.693271] 	item 3 key (20971520 168 4096) itemoff 3872 itemsize 51
[120180.693271] 		extent refs 1 gen 3555360 flags 2
[120180.693272] 		tree block key (1 216 1) level 0
[120180.693273] 		tree block backref root 3
[120180.693273] 	item 4 key (20971520 192 8388608) itemoff 3848 itemsize 24
[120180.693274] 		block group used 16384
[120180.693274] 	item 5 key (20975616 168 4096) itemoff 3797 itemsize 51
[120180.693275] 		extent refs 1 gen 3555360 flags 2
[120180.693275] 		tree block key (1 216 1) level 1
[120180.693276] 		tree block backref root 3
[120180.693276] 	item 6 key (20979712 168 4096) itemoff 3746 itemsize 51
[120180.693277] 		extent refs 1 gen 3555360 flags 2
[120180.693278] 		tree block key (256 228 15061745664) level 0
[120180.693278] 		tree block backref root 3
[120180.693279] 	item 7 key (20983808 168 4096) itemoff 3695 itemsize 51
[120180.693279] 		extent refs 1 gen 3555360 flags 2
[120180.693280] 		tree block key (256 228 76265029632) level 0
[120180.693280] 		tree block backref root 3
[120180.693281] 	item 8 key (29360128 192 1073741824) itemoff 3671 itemsize 24
[120180.693281] 		block group used 0
[120180.693282] 	item 9 key (1103101952 192 1073741824) itemoff 3647 itemsize 24
[120180.693282] 		block group used 0
[120180.693283] 	item 10 key (2176843776 192 1073741824) itemoff 3623 itemsize 24
[120180.693283] 		block group used 0
[120180.693284] 	item 11 key (3250585600 192 1073741824) itemoff 3599 itemsize 24
[120180.693284] 		block group used 0
[120180.693285] 	item 12 key (4324327424 192 1073741824) itemoff 3575 itemsize 24
[120180.693285] 		block group used 0
[120180.693286] 	item 13 key (5398069248 192 1073741824) itemoff 3551 itemsize 24
[120180.693287] 		block group used 0
[120180.693287] 	item 14 key (6471811072 192 1073741824) itemoff 3527 itemsize 24
[120180.693288] 		block group used 0
[120180.693288] 	item 15 key (7545552896 192 1073741824) itemoff 3503 itemsize 24
[120180.693289] 		block group used 0
[120180.693289] 	item 16 key (8619294720 192 1073741824) itemoff 3479 itemsize 24
[120180.693290] 		block group used 0
[120180.693290] 	item 17 key (9693036544 192 1073741824) itemoff 3455 itemsize 24
[120180.693291] 		block group used 0
[120180.693291] 	item 18 key (10766778368 192 1073741824) itemoff 3431 itemsize 24
[120180.693292] 		block group used 0
[120180.693292] 	item 19 key (11840520192 192 1073741824) itemoff 3407 itemsize 24
[120180.693293] 		block group used 0
[120180.693293] 	item 20 key (12914262016 192 1073741824) itemoff 3383 itemsize 24
[120180.693294] 		block group used 0
[120180.693294] 	item 21 key (13988003840 192 1073741824) itemoff 3359 itemsize 24
[120180.693295] 		block group used 0
[120180.693295] 	item 22 key (15061745664 192 1073741824) itemoff 3335 itemsize 24
[120180.693296] 		block group used 0
[120180.693297] 	item 23 key (16135487488 192 1073741824) itemoff 3311 itemsize 24
[120180.693297] 		block group used 0
[120180.693298] 	item 24 key (17209229312 192 1073741824) itemoff 3287 itemsize 24
[120180.693298] 		block group used 0
[120180.693299] 	item 25 key (18282971136 192 1073741824) itemoff 3263 itemsize 24
[120180.693299] 		block group used 0
[120180.693300] 	item 26 key (19356712960 192 1073741824) itemoff 3239 itemsize 24
[120180.693300] 		block group used 0
[120180.693301] 	item 27 key (20430454784 192 1073741824) itemoff 3215 itemsize 24
[120180.693301] 		block group used 0
[120180.693302] 	item 28 key (21504196608 192 1073741824) itemoff 3191 itemsize 24
[120180.693302] 		block group used 0
[120180.693303] 	item 29 key (22577938432 192 1073741824) itemoff 3167 itemsize 24
[120180.693303] 		block group used 0
[120180.693304] 	item 30 key (23651680256 192 1073741824) itemoff 3143 itemsize 24
[120180.693304] 		block group used 0
[120180.693305] 	item 31 key (24725422080 192 1073741824) itemoff 3119 itemsize 24
[120180.693305] 		block group used 0
[120180.693306] 	item 32 key (25799163904 192 1073741824) itemoff 3095 itemsize 24
[120180.693306] 		block group used 0
[120180.693307] 	item 33 key (26872905728 192 1073741824) itemoff 3071 itemsize 24
[120180.693307] 		block group used 0
[120180.693308] 	item 34 key (27946647552 192 1073741824) itemoff 3047 itemsize 24
[120180.693308] 		block group used 0
[120180.693309] 	item 35 key (29020389376 192 1073741824) itemoff 3023 itemsize 24
[120180.693309] 		block group used 0
[120180.693310] 	item 36 key (30094131200 192 1073741824) itemoff 2999 itemsize 24
[120180.693310] 		block group used 0
[120180.693310] 	item 37 key (31167873024 192 1073741824) itemoff 2975 itemsize 24
[120180.693310] 		block group used 0
[120180.693311] 	item 38 key (32241614848 192 1073741824) itemoff 2951 itemsize 24
[120180.693311] 		block group used 0
[120180.693311] 	item 39 key (33315356672 192 1073741824) itemoff 2927 itemsize 24
[120180.693311] 		block group used 0
[120180.693312] 	item 40 key (37610323968 192 1073741824) itemoff 2903 itemsize 24
[120180.693312] 		block group used 0
[120180.693312] 	item 41 key (38684065792 192 1073741824) itemoff 2879 itemsize 24
[120180.693312] 		block group used 0
[120180.693312] 	item 42 key (39757807616 192 1073741824) itemoff 2855 itemsize 24
[120180.693313] 		block group used 0
[120180.693313] BTRFS error (device dm-7): unable to find ref byte nr 785379328 parent 0 root 5  owner 1 offset 0
[120180.693314] BTRFS: error (device dm-7) in __btrfs_free_extent:6599: errno=-2 No such entry
[120180.693314] BTRFS: error (device dm-7) in btrfs_run_delayed_refs:2946: errno=-2 No such entry
[120180.728720] pending csums is 1310720
[120183.612867] BTRFS error (device dm-7): cleaner transaction attach returned -30

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2016-10-23 19:42 How to recover a filesystem without formatting nor using the btrfs check command none
@ 2016-10-24  1:15 ` Qu Wenruo
       [not found]   ` <36f56365-27ac-878e-c5fb-f414646eda3a@sdf-eu.org>
  0 siblings, 1 reply; 11+ messages in thread
From: Qu Wenruo @ 2016-10-24  1:15 UTC (permalink / raw)
  To: none, linux-btrfs

You could try to use --mode lowmem, which doesn't ever use any loop to 
get next block, but iterating trees.

Current in mainline btrfs-progs, the low memory mode code only checks 
extent/chunk trees, file/subvolume trees are still checked by original mode.

You could try the devel branch from David, which now contains the full 
low memory mode check code:
https://github.com/kdave/btrfs-progs/tree/devel

Although low memory mode doesn't support repair yet, it would give us 
enough info on what's corrupted, so we can later fix it by hand or 
enhance original mode.

Thanks,
Qu

At 10/24/2016 03:42 AM, none wrote:
> Hello,
> I have the following bug
> https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, is
> there a way to recover my filesystem in clean state without formatting
> or using btrsfck ? Of course, the point is no longer need the files
> which are damaged.
> So is there a way to recover a btrfs filesystem by deleting the
> corrupted data instead of trying to restore it ?
>
> btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
> Data, single: total=66.01GiB, used=0.00B
> System, DUP: total=8.00MiB, used=16.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, DUP: total=5.00GiB, used=28.00KiB
> Metadata, single: total=8.00MiB, used=0.00B
> GlobalReserve, single: total=4.00MiB, used=0.00B
>
> btrfs progs version 4.7.3 from Devuan
>
> Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
>         Total devices 1 FS bytes used 44.00KiB
>         devid    1 size 298.91GiB used 76.04GiB path
> /dev/mapper/isw_bdffeeeijj_Volume0p7
>
> uname -a
> Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1
> (2016-04-20) x86_64 GNU/Linux
>
> Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 :
> https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz
>
>
> Thanks,
>



^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
       [not found]   ` <36f56365-27ac-878e-c5fb-f414646eda3a@sdf-eu.org>
@ 2016-10-25  3:04     ` Qu Wenruo
  2016-10-25 18:19       ` none
  0 siblings, 1 reply; 11+ messages in thread
From: Qu Wenruo @ 2016-10-25  3:04 UTC (permalink / raw)
  To: none, btrfs



At 10/25/2016 01:54 AM, none wrote:
> So do you mean lowmem is also low cpu ?

Not sure, but lowmem is high IO.
And by design, it won't cause dead look unless there is a looping tree 
block. But that will be detected by check_tree_block().

So, it just avoids any possible dead loop AFAIK.

> Indeed here's the output if the metadata image isn't enough (it
> termintes correctly with the --lowmem option). I must recognize even
> without the --repair option, btrfs check hangs.

I just forgot you have uploaded the image dump.
I'll check it.

But according to lowmem output, it seems all your extent tree is screwed 
up, maybe that's the cause of the problem?

Thanks,
Qu
>
> regards,
>
> Le 24/10/2016 à 03:15, Qu Wenruo a écrit :
>
>> You could try to use --mode lowmem, which doesn't ever use any loop to
>> get next block, but iterating trees.
>>
>> Current in mainline btrfs-progs, the low memory mode code only checks
>> extent/chunk trees, file/subvolume trees are still checked by original
>> mode.
>>
>> You could try the devel branch from David, which now contains the full
>> low memory mode check code:
>> https://github.com/kdave/btrfs-progs/tree/devel
>>
>> Although low memory mode doesn't support repair yet, it would give us
>> enough info on what's corrupted, so we can later fix it by hand or
>> enhance original mode.
>>
>> Thanks,
>> Qu
>>
>> At 10/24/2016 03:42 AM, none wrote:
>>
>>> Hello,
>>> I have the following bug
>>> https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, is
>>> there a way to recover my filesystem in clean state without formatting
>>> or using btrsfck ? Of course, the point is no longer need the files
>>> which are damaged.
>>> So is there a way to recover a btrfs filesystem by deleting the
>>> corrupted data instead of trying to restore it ?
>>>
>>> btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
>>> Data, single: total=66.01GiB, used=0.00B
>>> System, DUP: total=8.00MiB, used=16.00KiB
>>> System, single: total=4.00MiB, used=0.00B
>>> Metadata, DUP: total=5.00GiB, used=28.00KiB
>>> Metadata, single: total=8.00MiB, used=0.00B
>>> GlobalReserve, single: total=4.00MiB, used=0.00B
>>>
>>> btrfs progs version 4.7.3 from Devuan
>>>
>>> Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
>>> Total devices 1 FS bytes used 44.00KiB
>>> devid    1 size 298.91GiB used 76.04GiB path
>>> /dev/mapper/isw_bdffeeeijj_Volume0p7
>>>
>>> uname -a
>>> Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1
>>> (2016-04-20) x86_64 GNU/Linux
>>>
>>> Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 :
>>> https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz
>>>
>>>
>>> Thanks,
>



^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2016-10-25  3:04     ` Qu Wenruo
@ 2016-10-25 18:19       ` none
  2016-10-26  1:43         ` Qu Wenruo
  0 siblings, 1 reply; 11+ messages in thread
From: none @ 2016-10-25 18:19 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Qu Wenruo

Le 2016-10-25 05:04, Qu Wenruo a écrit :
> At 10/25/2016 01:54 AM, none wrote:
>> So do you mean lowmem is also low cpu ?
> 
> Not sure, but lowmem is high IO.
> And by design, it won't cause dead look unless there is a looping tree
> block. But that will be detected by check_tree_block().
> 
> So, it just avoids any possible dead loop AFAIK.
> 
>> Indeed here's the output if the metadata image isn't enough (it
>> termintes correctly with the --lowmem option). I must recognize even
>> without the --repair option, btrfs check hangs.
> 
> I just forgot you have uploaded the image dump.
> I'll check it.
> 
> But according to lowmem output, it seems all your extent tree is
> screwed up, maybe that's the cause of the problem?
I don’t think so, I can read and write to most files and no directory is 
corrupt (even after running the btrfsck with lowmem).

But of course, as the filesystem is corrupt, I avoid to mount it.

Looks like the output of the tool is wrong.
> 
> Thanks,
> Qu
>> 
>> regards,
>> 
>> Le 24/10/2016 à 03:15, Qu Wenruo a écrit :
>> 
>>> You could try to use --mode lowmem, which doesn't ever use any loop 
>>> to
>>> get next block, but iterating trees.
>>> 
>>> Current in mainline btrfs-progs, the low memory mode code only checks
>>> extent/chunk trees, file/subvolume trees are still checked by 
>>> original
>>> mode.
>>> 
>>> You could try the devel branch from David, which now contains the 
>>> full
>>> low memory mode check code:
>>> https://github.com/kdave/btrfs-progs/tree/devel
>>> 
>>> Although low memory mode doesn't support repair yet, it would give us
>>> enough info on what's corrupted, so we can later fix it by hand or
>>> enhance original mode.
>>> 
>>> Thanks,
>>> Qu
>>> 
>>> At 10/24/2016 03:42 AM, none wrote:
>>> 
>>>> Hello,
>>>> I have the following bug
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, 
>>>> is
>>>> there a way to recover my filesystem in clean state without 
>>>> formatting
>>>> or using btrsfck ? Of course, the point is no longer need the files
>>>> which are damaged.
>>>> So is there a way to recover a btrfs filesystem by deleting the
>>>> corrupted data instead of trying to restore it ?
>>>> 
>>>> btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
>>>> Data, single: total=66.01GiB, used=0.00B
>>>> System, DUP: total=8.00MiB, used=16.00KiB
>>>> System, single: total=4.00MiB, used=0.00B
>>>> Metadata, DUP: total=5.00GiB, used=28.00KiB
>>>> Metadata, single: total=8.00MiB, used=0.00B
>>>> GlobalReserve, single: total=4.00MiB, used=0.00B
>>>> 
>>>> btrfs progs version 4.7.3 from Devuan
>>>> 
>>>> Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
>>>> Total devices 1 FS bytes used 44.00KiB
>>>> devid    1 size 298.91GiB used 76.04GiB path
>>>> /dev/mapper/isw_bdffeeeijj_Volume0p7
>>>> 
>>>> uname -a
>>>> Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1
>>>> (2016-04-20) x86_64 GNU/Linux
>>>> 
>>>> Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 :
>>>> https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz
>>>> 
>>>> 
>>>> Thanks,
>> 


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2016-10-25 18:19       ` none
@ 2016-10-26  1:43         ` Qu Wenruo
  2016-10-26 11:52           ` none
  2016-10-26 19:03           ` none
  0 siblings, 2 replies; 11+ messages in thread
From: Qu Wenruo @ 2016-10-26  1:43 UTC (permalink / raw)
  To: none, linux-btrfs

Unfortunately, low memory mode is right here.

If btrfs-image dump the image correctly, your extent tree is really 
screwed up.

And how badly it is screwed up?
It only contains the basic block group info.
Almost empty, without any really useful EXTENT_ITEM/METADATA_ITEM.

You can check it by btrfs-debug-tree -t extent.
Normally, one EXTENT_DATA or tree block should have corresponding 
EXTENT_ITEM or METADATA_ITEM in extent tree.

But in your dump, I only find EXTENT_ITEM less than a dozen, which is 
totally abnormal for the used size of your fs.

That's why lowmem mode is reporting so many backref lost.

It's almost a miracle that you can still write data into the fs.
And I heavily doubt the correctness of your existing files.

As extent tree is screwed up, it's completely possible new write are 
overwriting existing data.

The only chance seems to be --init-extent-tree, but that's very 
dangerous and I highly suspect the screwed up extent tree is caused by 
interrupted extent tree rebuild.

Thanks,
Qu

At 10/26/2016 02:19 AM, none wrote:
> Le 2016-10-25 05:04, Qu Wenruo a écrit :
>> At 10/25/2016 01:54 AM, none wrote:
>>> So do you mean lowmem is also low cpu ?
>>
>> Not sure, but lowmem is high IO.
>> And by design, it won't cause dead look unless there is a looping tree
>> block. But that will be detected by check_tree_block().
>>
>> So, it just avoids any possible dead loop AFAIK.
>>
>>> Indeed here's the output if the metadata image isn't enough (it
>>> termintes correctly with the --lowmem option). I must recognize even
>>> without the --repair option, btrfs check hangs.
>>
>> I just forgot you have uploaded the image dump.
>> I'll check it.
>>
>> But according to lowmem output, it seems all your extent tree is
>> screwed up, maybe that's the cause of the problem?
> I don’t think so, I can read and write to most files and no directory is
> corrupt (even after running the btrfsck with lowmem).
>
> But of course, as the filesystem is corrupt, I avoid to mount it.
>
> Looks like the output of the tool is wrong.
>>
>> Thanks,
>> Qu
>>>
>>> regards,
>>>
>>> Le 24/10/2016 à 03:15, Qu Wenruo a écrit :
>>>
>>>> You could try to use --mode lowmem, which doesn't ever use any loop to
>>>> get next block, but iterating trees.
>>>>
>>>> Current in mainline btrfs-progs, the low memory mode code only checks
>>>> extent/chunk trees, file/subvolume trees are still checked by original
>>>> mode.
>>>>
>>>> You could try the devel branch from David, which now contains the full
>>>> low memory mode check code:
>>>> https://github.com/kdave/btrfs-progs/tree/devel
>>>>
>>>> Although low memory mode doesn't support repair yet, it would give us
>>>> enough info on what's corrupted, so we can later fix it by hand or
>>>> enhance original mode.
>>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>> At 10/24/2016 03:42 AM, none wrote:
>>>>
>>>>> Hello,
>>>>> I have the following bug
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, is
>>>>> there a way to recover my filesystem in clean state without formatting
>>>>> or using btrsfck ? Of course, the point is no longer need the files
>>>>> which are damaged.
>>>>> So is there a way to recover a btrfs filesystem by deleting the
>>>>> corrupted data instead of trying to restore it ?
>>>>>
>>>>> btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
>>>>> Data, single: total=66.01GiB, used=0.00B
>>>>> System, DUP: total=8.00MiB, used=16.00KiB
>>>>> System, single: total=4.00MiB, used=0.00B
>>>>> Metadata, DUP: total=5.00GiB, used=28.00KiB
>>>>> Metadata, single: total=8.00MiB, used=0.00B
>>>>> GlobalReserve, single: total=4.00MiB, used=0.00B
>>>>>
>>>>> btrfs progs version 4.7.3 from Devuan
>>>>>
>>>>> Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
>>>>> Total devices 1 FS bytes used 44.00KiB
>>>>> devid    1 size 298.91GiB used 76.04GiB path
>>>>> /dev/mapper/isw_bdffeeeijj_Volume0p7
>>>>>
>>>>> uname -a
>>>>> Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1
>>>>> (2016-04-20) x86_64 GNU/Linux
>>>>>
>>>>> Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 :
>>>>> https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>
>
>
>



^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2016-10-26  1:43         ` Qu Wenruo
@ 2016-10-26 11:52           ` none
  2016-10-27  1:11             ` Qu Wenruo
  2016-10-26 19:03           ` none
  1 sibling, 1 reply; 11+ messages in thread
From: none @ 2016-10-26 11:52 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Qu Wenruo

Le 2016-10-26 03:43, Qu Wenruo a écrit :
> Unfortunately, low memory mode is right here.
> 
> If btrfs-image dump the image correctly, your extent tree is really 
> screwed up.
> 
> And how badly it is screwed up?
> It only contains the basic block group info.
> Almost empty, without any really useful EXTENT_ITEM/METADATA_ITEM.
> You can check it by btrfs-debug-tree -t extent.
> Normally, one EXTENT_DATA or tree block should have corresponding
> EXTENT_ITEM or METADATA_ITEM in extent tree.
> 
> But in your dump, I only find EXTENT_ITEM less than a dozen, which is
> totally abnormal for the used size of your fs.
Please note df -h report 55Gb used due to a very high compression ratio. 
Basically most of the theoretical used space is done by less than 100 
files. I want to delete them
> That's why lowmem mode is reporting so many backref lost.
Whithout the lowmem mode, only 3 lines are reported :

Failed to find [75191291904, 168, 4096]
btrfs unable to find ref byte nr 75191291904 parent 0 root 1  owner 1 
offset 0
Failed to find [75191316480, 168, 4096]
btrfs unable to find ref byte nr 75191316480 parent 0 root 1  owner 0 
offset 1
parent transid verify failed on 75191349248 wanted 3555361 found 3555362
Ignoring transid failure

and then it’s cpu locked.

> It's almost a miracle that you can still write data into the fs.
> And I heavily doubt the correctness of your existing files.
They are definitely correct. I have several root filesystem and I can 
chroot to all of them (though I’m mounting the partition readonly in 
order to avoid dangerous writes in that case). In each case I tried 
python and ruby cgi scripts.
> As extent tree is screwed up, it's completely possible new write are
> overwriting existing data.
Though I only attempted to write to 3 files. But yes, this was something 
I suspected : that writing damage things.
> The only chance seems to be --init-extent-tree, but that's very
> dangerous and I highly suspect the screwed up extent tree is caused by
> interrupted extent tree rebuild.
The problem is --init-extent-tree implies --repair which discard 
--mode=lowmem and cause the dead lock : 
https://bugzilla.kernel.org/show_bug.cgi?id=178781
> Thanks,
> Qu
> 
And finally, I found several corrupt directories yesterday.

Do you mean it’s impossible to rescue anything by repairing ? (this is 
something I doubt since most files are valid)

Thank you.
> At 10/26/2016 02:19 AM, none wrote:
>> Le 2016-10-25 05:04, Qu Wenruo a écrit :
>>> At 10/25/2016 01:54 AM, none wrote:
>>>> So do you mean lowmem is also low cpu ?
>>> 
>>> Not sure, but lowmem is high IO.
>>> And by design, it won't cause dead look unless there is a looping 
>>> tree
>>> block. But that will be detected by check_tree_block().
>>> 
>>> So, it just avoids any possible dead loop AFAIK.
>>> 
>>>> Indeed here's the output if the metadata image isn't enough (it
>>>> termintes correctly with the --lowmem option). I must recognize even
>>>> without the --repair option, btrfs check hangs.
>>> 
>>> I just forgot you have uploaded the image dump.
>>> I'll check it.
>>> 
>>> But according to lowmem output, it seems all your extent tree is
>>> screwed up, maybe that's the cause of the problem?
>> I don’t think so, I can read and write to most files and no directory 
>> is
>> corrupt (even after running the btrfsck with lowmem).
>> 
>> But of course, as the filesystem is corrupt, I avoid to mount it.
>> 
>> Looks like the output of the tool is wrong.
>>> 
>>> Thanks,
>>> Qu
>>>> 
>>>> regards,
>>>> 
>>>> Le 24/10/2016 à 03:15, Qu Wenruo a écrit :
>>>> 
>>>>> You could try to use --mode lowmem, which doesn't ever use any loop 
>>>>> to
>>>>> get next block, but iterating trees.
>>>>> 
>>>>> Current in mainline btrfs-progs, the low memory mode code only 
>>>>> checks
>>>>> extent/chunk trees, file/subvolume trees are still checked by 
>>>>> original
>>>>> mode.
>>>>> 
>>>>> You could try the devel branch from David, which now contains the 
>>>>> full
>>>>> low memory mode check code:
>>>>> https://github.com/kdave/btrfs-progs/tree/devel
>>>>> 
>>>>> Although low memory mode doesn't support repair yet, it would give 
>>>>> us
>>>>> enough info on what's corrupted, so we can later fix it by hand or
>>>>> enhance original mode.
>>>>> 
>>>>> Thanks,
>>>>> Qu
>>>>> 
>>>>> At 10/24/2016 03:42 AM, none wrote:
>>>>> 
>>>>>> Hello,
>>>>>> I have the following bug
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, 
>>>>>> is
>>>>>> there a way to recover my filesystem in clean state without 
>>>>>> formatting
>>>>>> or using btrsfck ? Of course, the point is no longer need the 
>>>>>> files
>>>>>> which are damaged.
>>>>>> So is there a way to recover a btrfs filesystem by deleting the
>>>>>> corrupted data instead of trying to restore it ?
>>>>>> 
>>>>>> btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
>>>>>> Data, single: total=66.01GiB, used=0.00B
>>>>>> System, DUP: total=8.00MiB, used=16.00KiB
>>>>>> System, single: total=4.00MiB, used=0.00B
>>>>>> Metadata, DUP: total=5.00GiB, used=28.00KiB
>>>>>> Metadata, single: total=8.00MiB, used=0.00B
>>>>>> GlobalReserve, single: total=4.00MiB, used=0.00B
>>>>>> 
>>>>>> btrfs progs version 4.7.3 from Devuan
>>>>>> 
>>>>>> Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
>>>>>> Total devices 1 FS bytes used 44.00KiB
>>>>>> devid    1 size 298.91GiB used 76.04GiB path
>>>>>> /dev/mapper/isw_bdffeeeijj_Volume0p7
>>>>>> 
>>>>>> uname -a
>>>>>> Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1
>>>>>> (2016-04-20) x86_64 GNU/Linux
>>>>>> 
>>>>>> Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 :
>>>>>> https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks,

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2016-10-26  1:43         ` Qu Wenruo
  2016-10-26 11:52           ` none
@ 2016-10-26 19:03           ` none
  1 sibling, 0 replies; 11+ messages in thread
From: none @ 2016-10-26 19:03 UTC (permalink / raw)
  To: linux-btrfs

Le 2016-10-26 03:43, Qu Wenruo a écrit :
> Unfortunately, low memory mode is right here.
> 
> If btrfs-image dump the image correctly, your extent tree is really 
> screwed up.
> 
> And how badly it is screwed up?
> It only contains the basic block group info.
> Almost empty, without any really useful EXTENT_ITEM/METADATA_ITEM.
> You can check it by btrfs-debug-tree -t extent.
> Normally, one EXTENT_DATA or tree block should have corresponding
> EXTENT_ITEM or METADATA_ITEM in extent tree.
> 
> But in your dump, I only find EXTENT_ITEM less than a dozen, which is
> totally abnormal for the used size of your fs.
Please note df -h report 55Gb used due to a very high compression ratio. 
Basically most of the theoretical used space is done by less than 100 
files. I want to delete them
> That's why lowmem mode is reporting so many backref lost.
Whithout the lowmem mode, only 3 lines are reported :

Failed to find [75191291904, 168, 4096]
btrfs unable to find ref byte nr 75191291904 parent 0 root 1  owner 1 
offset 0
Failed to find [75191316480, 168, 4096]
btrfs unable to find ref byte nr 75191316480 parent 0 root 1  owner 0 
offset 1
parent transid verify failed on 75191349248 wanted 3555361 found 3555362
Ignoring transid failure

and then it’s cpu locked.

> It's almost a miracle that you can still write data into the fs.
> And I heavily doubt the correctness of your existing files.
They are definitely correct. I have several root filesystem and I can 
chroot to all of them (though I’m mounting the partition readonly in 
order to avoid dangerous writes in that case). In each case I tried 
python and ruby cgi scripts.
> As extent tree is screwed up, it's completely possible new write are
> overwriting existing data.
Though I only attempted to write to 3 files. But yes, this was something 
I suspected : that writing damage things.
> The only chance seems to be --init-extent-tree, but that's very
> dangerous and I highly suspect the screwed up extent tree is caused by
> interrupted extent tree rebuild.
The problem is --init-extent-tree implies --repair which discard 
--mode=lowmem and cause the dead lock : 
https://bugzilla.kernel.org/show_bug.cgi?id=178781
> Thanks,
> Qu
> 
And finally, I found several corrupt directories yesterday.

Do you mean it’s impossible to rescue anything by repairing ? (this is 
something I doubt since most files are valid)

Thank you.

> At 10/26/2016 02:19 AM, none wrote:
>> Le 2016-10-25 05:04, Qu Wenruo a écrit :
>>> At 10/25/2016 01:54 AM, none wrote:
>>>> So do you mean lowmem is also low cpu ?
>>> 
>>> Not sure, but lowmem is high IO.
>>> And by design, it won't cause dead look unless there is a looping 
>>> tree
>>> block. But that will be detected by check_tree_block().
>>> 
>>> So, it just avoids any possible dead loop AFAIK.
>>> 
>>>> Indeed here's the output if the metadata image isn't enough (it
>>>> termintes correctly with the --lowmem option). I must recognize even
>>>> without the --repair option, btrfs check hangs.
>>> 
>>> I just forgot you have uploaded the image dump.
>>> I'll check it.
>>> 
>>> But according to lowmem output, it seems all your extent tree is
>>> screwed up, maybe that's the cause of the problem?
>> I don’t think so, I can read and write to most files and no directory 
>> is
>> corrupt (even after running the btrfsck with lowmem).
>> 
>> But of course, as the filesystem is corrupt, I avoid to mount it.
>> 
>> Looks like the output of the tool is wrong.
>>> 
>>> Thanks,
>>> Qu
>>>> 
>>>> regards,
>>>> 
>>>> Le 24/10/2016 à 03:15, Qu Wenruo a écrit :
>>>> 
>>>>> You could try to use --mode lowmem, which doesn't ever use any loop 
>>>>> to
>>>>> get next block, but iterating trees.
>>>>> 
>>>>> Current in mainline btrfs-progs, the low memory mode code only 
>>>>> checks
>>>>> extent/chunk trees, file/subvolume trees are still checked by 
>>>>> original
>>>>> mode.
>>>>> 
>>>>> You could try the devel branch from David, which now contains the 
>>>>> full
>>>>> low memory mode check code:
>>>>> https://github.com/kdave/btrfs-progs/tree/devel
>>>>> 
>>>>> Although low memory mode doesn't support repair yet, it would give 
>>>>> us
>>>>> enough info on what's corrupted, so we can later fix it by hand or
>>>>> enhance original mode.
>>>>> 
>>>>> Thanks,
>>>>> Qu
>>>>> 
>>>>> At 10/24/2016 03:42 AM, none wrote:
>>>>> 
>>>>>> Hello,
>>>>>> I have the following bug
>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, 
>>>>>> is
>>>>>> there a way to recover my filesystem in clean state without 
>>>>>> formatting
>>>>>> or using btrsfck ? Of course, the point is no longer need the 
>>>>>> files
>>>>>> which are damaged.
>>>>>> So is there a way to recover a btrfs filesystem by deleting the
>>>>>> corrupted data instead of trying to restore it ?
>>>>>> 
>>>>>> btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
>>>>>> Data, single: total=66.01GiB, used=0.00B
>>>>>> System, DUP: total=8.00MiB, used=16.00KiB
>>>>>> System, single: total=4.00MiB, used=0.00B
>>>>>> Metadata, DUP: total=5.00GiB, used=28.00KiB
>>>>>> Metadata, single: total=8.00MiB, used=0.00B
>>>>>> GlobalReserve, single: total=4.00MiB, used=0.00B
>>>>>> 
>>>>>> btrfs progs version 4.7.3 from Devuan
>>>>>> 
>>>>>> Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
>>>>>> Total devices 1 FS bytes used 44.00KiB
>>>>>> devid    1 size 298.91GiB used 76.04GiB path
>>>>>> /dev/mapper/isw_bdffeeeijj_Volume0p7
>>>>>> 
>>>>>> uname -a
>>>>>> Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1
>>>>>> (2016-04-20) x86_64 GNU/Linux
>>>>>> 
>>>>>> Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 :
>>>>>> https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>> 
>> 
>> 
>> 


^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2016-10-26 11:52           ` none
@ 2016-10-27  1:11             ` Qu Wenruo
  2017-01-01 23:29               ` none
  0 siblings, 1 reply; 11+ messages in thread
From: Qu Wenruo @ 2016-10-27  1:11 UTC (permalink / raw)
  To: none, linux-btrfs



At 10/26/2016 07:52 PM, none wrote:
> Le 2016-10-26 03:43, Qu Wenruo a écrit :
>> Unfortunately, low memory mode is right here.
>>
>> If btrfs-image dump the image correctly, your extent tree is really
>> screwed up.
>>
>> And how badly it is screwed up?
>> It only contains the basic block group info.
>> Almost empty, without any really useful EXTENT_ITEM/METADATA_ITEM.
>> You can check it by btrfs-debug-tree -t extent.
>> Normally, one EXTENT_DATA or tree block should have corresponding
>> EXTENT_ITEM or METADATA_ITEM in extent tree.
>>
>> But in your dump, I only find EXTENT_ITEM less than a dozen, which is
>> totally abnormal for the used size of your fs.
> Please note df -h report 55Gb used due to a very high compression ratio.
> Basically most of the theoretical used space is done by less than 100
> files. I want to delete them
>> That's why lowmem mode is reporting so many backref lost.
> Whithout the lowmem mode, only 3 lines are reported :
>
> Failed to find [75191291904, 168, 4096]
> btrfs unable to find ref byte nr 75191291904 parent 0 root 1  owner 1
> offset 0
> Failed to find [75191316480, 168, 4096]
> btrfs unable to find ref byte nr 75191316480 parent 0 root 1  owner 0
> offset 1
> parent transid verify failed on 75191349248 wanted 3555361 found 3555362
> Ignoring transid failure
>
> and then it’s cpu locked.

It's the dead loop make btrfsck only able to check the first several 
extents, no method to continue.

If we solve the dead loop, then there won't be less error report from 
original btrfsck.
(lowmem mode just avoid the possibility to dead loop by its design)

>
>> It's almost a miracle that you can still write data into the fs.
>> And I heavily doubt the correctness of your existing files.
> They are definitely correct. I have several root filesystem and I can
> chroot to all of them (though I’m mounting the partition readonly in
> order to avoid dangerous writes in that case). In each case I tried
> python and ruby cgi scripts.

You should check more, normally scrub will help, but considering the 
state of btrfs, scrub may not work at all or make things worse.

>> As extent tree is screwed up, it's completely possible new write are
>> overwriting existing data.
> Though I only attempted to write to 3 files. But yes, this was something
> I suspected : that writing damage things.
>> The only chance seems to be --init-extent-tree, but that's very
>> dangerous and I highly suspect the screwed up extent tree is caused by
>> interrupted extent tree rebuild.
> The problem is --init-extent-tree implies --repair which discard
> --mode=lowmem and cause the dead lock :
> https://bugzilla.kernel.org/show_bug.cgi?id=178781

Yes, that's the problem, and current situation may be caused by 
interrupted extent tree rebuild.

>> Thanks,
>> Qu
>>
> And finally, I found several corrupt directories yesterday.
>
> Do you mean it’s impossible to rescue anything by repairing ? (this is
> something I doubt since most files are valid)

Not completely, I'm digging into the dead loop problem, and after that 
you may still recover the fs(or part of it) using --init-extent-tree.

Thanks,
Qu

>
> Thank you.
>> At 10/26/2016 02:19 AM, none wrote:
>>> Le 2016-10-25 05:04, Qu Wenruo a écrit :
>>>> At 10/25/2016 01:54 AM, none wrote:
>>>>> So do you mean lowmem is also low cpu ?
>>>>
>>>> Not sure, but lowmem is high IO.
>>>> And by design, it won't cause dead look unless there is a looping tree
>>>> block. But that will be detected by check_tree_block().
>>>>
>>>> So, it just avoids any possible dead loop AFAIK.
>>>>
>>>>> Indeed here's the output if the metadata image isn't enough (it
>>>>> termintes correctly with the --lowmem option). I must recognize even
>>>>> without the --repair option, btrfs check hangs.
>>>>
>>>> I just forgot you have uploaded the image dump.
>>>> I'll check it.
>>>>
>>>> But according to lowmem output, it seems all your extent tree is
>>>> screwed up, maybe that's the cause of the problem?
>>> I don’t think so, I can read and write to most files and no directory is
>>> corrupt (even after running the btrfsck with lowmem).
>>>
>>> But of course, as the filesystem is corrupt, I avoid to mount it.
>>>
>>> Looks like the output of the tool is wrong.
>>>>
>>>> Thanks,
>>>> Qu
>>>>>
>>>>> regards,
>>>>>
>>>>> Le 24/10/2016 à 03:15, Qu Wenruo a écrit :
>>>>>
>>>>>> You could try to use --mode lowmem, which doesn't ever use any
>>>>>> loop to
>>>>>> get next block, but iterating trees.
>>>>>>
>>>>>> Current in mainline btrfs-progs, the low memory mode code only checks
>>>>>> extent/chunk trees, file/subvolume trees are still checked by
>>>>>> original
>>>>>> mode.
>>>>>>
>>>>>> You could try the devel branch from David, which now contains the
>>>>>> full
>>>>>> low memory mode check code:
>>>>>> https://github.com/kdave/btrfs-progs/tree/devel
>>>>>>
>>>>>> Although low memory mode doesn't support repair yet, it would give us
>>>>>> enough info on what's corrupted, so we can later fix it by hand or
>>>>>> enhance original mode.
>>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>
>>>>>> At 10/24/2016 03:42 AM, none wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>> I have the following bug
>>>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs
>>>>>>> check, is
>>>>>>> there a way to recover my filesystem in clean state without
>>>>>>> formatting
>>>>>>> or using btrsfck ? Of course, the point is no longer need the files
>>>>>>> which are damaged.
>>>>>>> So is there a way to recover a btrfs filesystem by deleting the
>>>>>>> corrupted data instead of trying to restore it ?
>>>>>>>
>>>>>>> btrfs fi df /mnt/Opera_Mobile_Emulator_12.1_Linux
>>>>>>> Data, single: total=66.01GiB, used=0.00B
>>>>>>> System, DUP: total=8.00MiB, used=16.00KiB
>>>>>>> System, single: total=4.00MiB, used=0.00B
>>>>>>> Metadata, DUP: total=5.00GiB, used=28.00KiB
>>>>>>> Metadata, single: total=8.00MiB, used=0.00B
>>>>>>> GlobalReserve, single: total=4.00MiB, used=0.00B
>>>>>>>
>>>>>>> btrfs progs version 4.7.3 from Devuan
>>>>>>>
>>>>>>> Label: 'backup'  uuid: 56040bbb-ed5c-47f2-82e2-34457bd7b4f3
>>>>>>> Total devices 1 FS bytes used 44.00KiB
>>>>>>> devid    1 size 298.91GiB used 76.04GiB path
>>>>>>> /dev/mapper/isw_bdffeeeijj_Volume0p7
>>>>>>>
>>>>>>> uname -a
>>>>>>> Linux localhost 4.5.0-0.bpo.1-amd64 #1 SMP Debian 4.5.1-1~bpo8+1
>>>>>>> (2016-04-20) x86_64 GNU/Linux
>>>>>>>
>>>>>>> Result of btrfs-image on /dev/mapper/isw_bdffeeeijj_Volume0p7 :
>>>>>>> https://web.archive.org/web/20161020220914/https://filebin.net/7ni8kfpog1dxw4jc/btrfs-image_capture.xz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>
>



^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2016-10-27  1:11             ` Qu Wenruo
@ 2017-01-01 23:29               ` none
  2017-01-03  6:11                 ` Qu Wenruo
  0 siblings, 1 reply; 11+ messages in thread
From: none @ 2017-01-01 23:29 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: linux-btrfs

Le 2016-10-27 03:11, Qu Wenruo a écrit :
> At 10/26/2016 07:52 PM, none wrote:
>> Le 2016-10-26 03:43, Qu Wenruo a écrit :
>>> Unfortunately, low memory mode is right here.
>>> 
>>> If btrfs-image dump the image correctly, your extent tree is really
>>> screwed up.
>>> 
>>> And how badly it is screwed up?
>>> It only contains the basic block group info.
>>> Almost empty, without any really useful EXTENT_ITEM/METADATA_ITEM.
>>> You can check it by btrfs-debug-tree -t extent.
>>> Normally, one EXTENT_DATA or tree block should have corresponding
>>> EXTENT_ITEM or METADATA_ITEM in extent tree.
>>> 
>>> But in your dump, I only find EXTENT_ITEM less than a dozen, which is
>>> totally abnormal for the used size of your fs.
>> Please note df -h report 55Gb used due to a very high compression 
>> ratio.
>> Basically most of the theoretical used space is done by less than 100
>> files. I want to delete them
>>> That's why lowmem mode is reporting so many backref lost.
>> Whithout the lowmem mode, only 3 lines are reported :
>> 
>> Failed to find [75191291904, 168, 4096]
>> btrfs unable to find ref byte nr 75191291904 parent 0 root 1  owner 1
>> offset 0
>> Failed to find [75191316480, 168, 4096]
>> btrfs unable to find ref byte nr 75191316480 parent 0 root 1  owner 0
>> offset 1
>> parent transid verify failed on 75191349248 wanted 3555361 found 
>> 3555362
>> Ignoring transid failure
>> 
>> and then it’s cpu locked.
> 
> It's the dead loop make btrfsck only able to check the first several
> extents, no method to continue.
> 
> If we solve the dead loop, then there won't be less error report from
> original btrfsck.
> (lowmem mode just avoid the possibility to dead loop by its design)
> 
>> 
>>> It's almost a miracle that you can still write data into the fs.
>>> And I heavily doubt the correctness of your existing files.
>> They are definitely correct. I have several root filesystem and I can
>> chroot to all of them (though I’m mounting the partition readonly in
>> order to avoid dangerous writes in that case). In each case I tried
>> python and ruby cgi scripts.
> 
> You should check more, normally scrub will help, but considering the
> state of btrfs, scrub may not work at all or make things worse.
> 
>>> As extent tree is screwed up, it's completely possible new write are
>>> overwriting existing data.
>> Though I only attempted to write to 3 files. But yes, this was 
>> something
>> I suspected : that writing damage things.
>>> The only chance seems to be --init-extent-tree, but that's very
>>> dangerous and I highly suspect the screwed up extent tree is caused 
>>> by
>>> interrupted extent tree rebuild.
>> The problem is --init-extent-tree implies --repair which discard
>> --mode=lowmem and cause the dead lock :
>> https://bugzilla.kernel.org/show_bug.cgi?id=178781
> 
> Yes, that's the problem, and current situation may be caused by
> interrupted extent tree rebuild.
> 
>>> Thanks,
>>> Qu
>>> 
>> And finally, I found several corrupt directories yesterday.
>> 
>> Do you mean it’s impossible to rescue anything by repairing ? (this is
>> something I doubt since most files are valid)
> 
> Not completely, I'm digging into the dead loop problem, and after that
> you may still recover the fs(or part of it) using --init-extent-tree.
> 
> Thanks,
> Qu
> 
>> 
>> Thank you.

Hello, what’s the status of my report since last October ?

thanks,

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2017-01-01 23:29               ` none
@ 2017-01-03  6:11                 ` Qu Wenruo
  2017-01-04 22:29                   ` none
  0 siblings, 1 reply; 11+ messages in thread
From: Qu Wenruo @ 2017-01-03  6:11 UTC (permalink / raw)
  To: none; +Cc: linux-btrfs

At 01/02/2017 07:29 AM, none wrote:
> Le 2016-10-27 03:11, Qu Wenruo a écrit :
>> At 10/26/2016 07:52 PM, none wrote:
>>> Le 2016-10-26 03:43, Qu Wenruo a écrit :
>>>> Unfortunately, low memory mode is right here.
>>>>
>>>> If btrfs-image dump the image correctly, your extent tree is really
>>>> screwed up.
>>>>
>>>> And how badly it is screwed up?
>>>> It only contains the basic block group info.
>>>> Almost empty, without any really useful EXTENT_ITEM/METADATA_ITEM.
>>>> You can check it by btrfs-debug-tree -t extent.
>>>> Normally, one EXTENT_DATA or tree block should have corresponding
>>>> EXTENT_ITEM or METADATA_ITEM in extent tree.
>>>>
>>>> But in your dump, I only find EXTENT_ITEM less than a dozen, which is
>>>> totally abnormal for the used size of your fs.
>>> Please note df -h report 55Gb used due to a very high compression ratio.
>>> Basically most of the theoretical used space is done by less than 100
>>> files. I want to delete them
>>>> That's why lowmem mode is reporting so many backref lost.
>>> Whithout the lowmem mode, only 3 lines are reported :
>>>
>>> Failed to find [75191291904, 168, 4096]
>>> btrfs unable to find ref byte nr 75191291904 parent 0 root 1  owner 1
>>> offset 0
>>> Failed to find [75191316480, 168, 4096]
>>> btrfs unable to find ref byte nr 75191316480 parent 0 root 1  owner 0
>>> offset 1
>>> parent transid verify failed on 75191349248 wanted 3555361 found 3555362
>>> Ignoring transid failure
>>>
>>> and then it’s cpu locked.
>>
>> It's the dead loop make btrfsck only able to check the first several
>> extents, no method to continue.
>>
>> If we solve the dead loop, then there won't be less error report from
>> original btrfsck.
>> (lowmem mode just avoid the possibility to dead loop by its design)
>>
>>>
>>>> It's almost a miracle that you can still write data into the fs.
>>>> And I heavily doubt the correctness of your existing files.
>>> They are definitely correct. I have several root filesystem and I can
>>> chroot to all of them (though I’m mounting the partition readonly in
>>> order to avoid dangerous writes in that case). In each case I tried
>>> python and ruby cgi scripts.
>>
>> You should check more, normally scrub will help, but considering the
>> state of btrfs, scrub may not work at all or make things worse.
>>
>>>> As extent tree is screwed up, it's completely possible new write are
>>>> overwriting existing data.
>>> Though I only attempted to write to 3 files. But yes, this was something
>>> I suspected : that writing damage things.
>>>> The only chance seems to be --init-extent-tree, but that's very
>>>> dangerous and I highly suspect the screwed up extent tree is caused by
>>>> interrupted extent tree rebuild.
>>> The problem is --init-extent-tree implies --repair which discard
>>> --mode=lowmem and cause the dead lock :
>>> https://bugzilla.kernel.org/show_bug.cgi?id=178781
>>
>> Yes, that's the problem, and current situation may be caused by
>> interrupted extent tree rebuild.
>>
>>>> Thanks,
>>>> Qu
>>>>
>>> And finally, I found several corrupt directories yesterday.
>>>
>>> Do you mean it’s impossible to rescue anything by repairing ? (this is
>>> something I doubt since most files are valid)
>>
>> Not completely, I'm digging into the dead loop problem, and after that
>> you may still recover the fs(or part of it) using --init-extent-tree.
>>
>> Thanks,
>> Qu
>>
>>>
>>> Thank you.
>
> Hello, what’s the status of my report since last October ?
>
> thanks,
>
>
Sorry for the late reply.

I tried your image but...
It's so slow, no matter the mode I'm using.

So I'm not sure if it's a deadlock since lowmem mode still takes several 
minuts and just output the same output.

The fs contains SOOOOOOOOO many reflinks and I can hardly determine if 
it's normal or deadlock.


Considering btrfs check original mode is using list to iteration 
backrefs, it can be very very slow, maybe O(n^3)~O(n^4).

And considering the number of reflinks, it can be longer than your 
assumption (maybe longer than 48 hours).

Just try xfstests generic/175, and see how slow btrfs check is.


And since your fs tree is super big, normal btrfs-debug-tree output will 
be over several GBs for debugging, this also makes things quite nasty to 
debug manually.

IMHO we only have 2 remaining methods to fix your fs:
1) Rework current backref structure.
    Use rb-tree other than list to iteration.
2) Introduce --init-extent-tree in lowmem mode.

Neither way it's a quick fix.
And I'm trying to implement the 2nd method first, but it may takes a lot 
of time.
(I still have a lot of other btrfs development to do, sorry)

I'd suggest you to rebuild the fs, considering the time we need to fix it.

Thanks,
Qu



^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: How to recover a filesystem without formatting nor using the btrfs check command.
  2017-01-03  6:11                 ` Qu Wenruo
@ 2017-01-04 22:29                   ` none
  0 siblings, 0 replies; 11+ messages in thread
From: none @ 2017-01-04 22:29 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: linux-btrfs

Le 2017-01-03 07:11, Qu Wenruo a écrit :
>> 
>> Hello, what’s the status of my report since last October ?
>> 
>> thanks,
>> 
>> 
> Sorry for the late reply.
> 
> I tried your image but...
> It's so slow, no matter the mode I'm using.
> 
> So I'm not sure if it's a deadlock since lowmem mode still takes
> several minuts and just output the same output.
Anyway, I got the lowmem mode finishing. But it didn’t solved my 
problem. I have a core i7‑6700k ᴄᴘᴜ
> The fs contains SOOOOOOOOO many reflinks and I can hardly determine if
> it's normal or deadlock.
> 
Yes, but most those reflinks are used only by a small number of sparse 
file whose content are made of 0 bits (they still represent several 
hundreds of Gb data). If those files can be deleted, then I should be 
able to btrfs the disk normally. (the problem is I can’t do it because 
of filesystem corruption)

I don’t know how much they are, but I think the number is high enough to 
make btrfscking the disk as hard as breaking encryption.

> Considering btrfs check original mode is using list to iteration
> backrefs, it can be very very slow, maybe O(n^3)~O(n^4).
> 
> And considering the number of reflinks, it can be longer than your
> assumption (maybe longer than 48 hours).

I tried running it and even after a week nothing is finished. I never 
assumed anything.

> Just try xfstests generic/175, and see how slow btrfs check is.
> 
> 
> And since your fs tree is super big, normal btrfs-debug-tree output
> will be over several GBs for debugging, this also makes things quite
> nasty to debug manually.
But most of the virtual space is used by only a small number of very 
large files which I agree to delete.

> IMHO we only have 2 remaining methods to fix your fs:
> 1) Rework current backref structure.
>    Use rb-tree other than list to iteration.
> 2) Introduce --init-extent-tree in lowmem mode.
> 
> Neither way it's a quick fix.
> And I'm trying to implement the 2nd method first, but it may takes a
> lot of time.
> (I still have a lot of other btrfs development to do, sorry)
> 
> I'd suggest you to rebuild the fs, considering the time we need to fix 
> it.
which I can’t, looks like it will takes some months to get a rce 
vulnerability in git to get fixed (before corrupting the filesystem, I 
saw ᴄᴠᴇ‑2016‑2315 was fixed incorrectly on GitHub servers).

As soon as I get access to my previous work data, I will be able to 
trace the root cause in ~1‒5 hours.
> Thanks,
> Qu
regards,

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-01-04 22:30 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-23 19:42 How to recover a filesystem without formatting nor using the btrfs check command none
2016-10-24  1:15 ` Qu Wenruo
     [not found]   ` <36f56365-27ac-878e-c5fb-f414646eda3a@sdf-eu.org>
2016-10-25  3:04     ` Qu Wenruo
2016-10-25 18:19       ` none
2016-10-26  1:43         ` Qu Wenruo
2016-10-26 11:52           ` none
2016-10-27  1:11             ` Qu Wenruo
2017-01-01 23:29               ` none
2017-01-03  6:11                 ` Qu Wenruo
2017-01-04 22:29                   ` none
2016-10-26 19:03           ` none

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.