All of lore.kernel.org
 help / color / mirror / Atom feed
* mounting failed any file on my filesystem
@ 2016-12-29 19:05 Jan Koester
  2016-12-29 22:31 ` Duncan
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Koester @ 2016-12-29 19:05 UTC (permalink / raw)
  To: linux-btrfs

Hi,

i have problem with filesystem if my system crashed i have made been hard reset 
of the system after my Filesystem was crashed. I have already tried to repair 
without success you can see it on log file. It's seem one corrupted block 
brings complete filesystem to crashing.

Have anybody idea what happened with my filesystem ?

dmesg if open file:
[29450.404327] WARNING: CPU: 5 PID: 16161 at /build/linux-lIgGMF/linux-4.8.11/
fs/btrfs/extent-tree.c:6945 __btrfs_free_extent.isra.71+0x8e2/0xd60 [btrfs]
[29450.404331] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi 
snd_seq_device nfnetlink_queue nfnetlink_log nfnetlink cfg80211 bnep 
ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter pci_stub 
vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bluetooth rfkill 
binfmt_misc ext4 crc16 jbd2 fscrypto ecb mbcache btrfs xor raid6_pq kvm_amd 
kvm amdkfd irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel radeon 
snd_hda_codec_realtek snd_hda_codec_generic sr_mod cdrom pcspkr serio_raw 
snd_hda_codec_hdmi fam15h_power k10temp evdev snd_hda_intel ttm snd_hda_codec 
drm_kms_helper snd_hda_core snd_hwdep snd_pcm drm snd_timer snd soundcore 
i2c_algo_bit sg sp5100_tco nuvoton_cir shpchp rc_core acpi_cpufreq tpm_tis 
tpm_tis_core tpm button cuse fuse parport_pc ppdev lp parport ip_tables
[29450.404512]  x_tables autofs4 xfs libcrc32c crc32c_generic ata_generic 
hid_generic usbhid hid sd_mod uas usb_storage ohci_pci crc32c_intel 
aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse 
e1000e xhci_pci r8169 xhci_hcd ptp ahci mii pps_core pata_atiixp libahci 
ohci_hcd libata ehci_pci ehci_hcd usbcore scsi_mod i2c_piix4 usb_common fjes
[29450.404543] CPU: 5 PID: 16161 Comm: kworker/u12:3 Tainted: G        W  OE   
4.8.0-2-amd64 #1 Debian 4.8.11-1
[29450.404544] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./
970 Extreme3, BIOS P1.80 07/31/2013
[29450.404579] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper [btrfs]
[29450.404581]  0000000000000286 000000000bc03c37 ffffffff93d269f5 
0000000000000000
[29450.404586]  0000000000000000 ffffffff93a7c16e 00000000fffffffe 
000000dd8f8a8000
[29450.404590]  0000000000000000 ffff91c65d625000 ffff91c4eac5c000 
ffff91c4e7c09690
[29450.404594] Call Trace:
[29450.404599]  [<ffffffff93d269f5>] ? dump_stack+0x5c/0x77
[29450.404603]  [<ffffffff93a7c16e>] ? __warn+0xbe/0xe0
[29450.404630]  [<ffffffffc0c262a2>] ? __btrfs_free_extent.isra.71+0x8e2/0xd60 
[btrfs]
[29450.404660]  [<ffffffffc0c20801>] ? block_group_cache_tree_search+0x21/0xd0 
[btrfs]
[29450.404690]  [<ffffffffc0c256d3>] ? update_block_group.isra.70+0x133/0x420 
[btrfs]
[29450.404699]  [<ffffffff93b8a9ff>] ? __set_page_dirty_nobuffers+0xef/0x140
[29450.404736]  [<ffffffffc0c95ab9>] ? btrfs_merge_delayed_refs+0x69/0x580 
[btrfs]
[29450.404767]  [<ffffffffc0c2a8ac>] ? __btrfs_run_delayed_refs+0xadc/0x1240 
[btrfs]
[29450.404801]  [<ffffffffc0c2deee>] ? btrfs_run_delayed_refs+0x8e/0x2a0 
[btrfs]
[29450.404834]  [<ffffffffc0c2e189>] ? delayed_ref_async_start+0x89/0xa0 
[btrfs]
[29450.404871]  [<ffffffffc0c788b1>] ? btrfs_scrubparity_helper+0xd1/0x2d0 
[btrfs]
[29450.404879]  [<ffffffff93a94e00>] ? process_one_work+0x160/0x410
[29450.404886]  [<ffffffff93a950fd>] ? worker_thread+0x4d/0x480
[29450.404892]  [<ffffffff93a950b0>] ? process_one_work+0x410/0x410
[29450.404899]  [<ffffffff93a9aecd>] ? kthread+0xcd/0xf0
[29450.404906]  [<ffffffff93fefcaf>] ? ret_from_fork+0x1f/0x40
[29450.404913]  [<ffffffff93a9ae00>] ? kthread_create_on_node+0x190/0x190
[29450.404919] ---[ end trace 9627fcfceb44da0b ]---
[29450.404926] BTRFS info (device sdd): leaf 950359678976 total ptrs 67 free 
space 442
[29450.404934]  item 0 key (503649468416 192 1107296256) itemoff 3971 itemsize 
24
[29450.404940]          block group used 36864
[29450.404947]  item 1 key (503649538048 169 0) itemoff 3938 itemsize 33
[29450.404952]          extent refs 1 gen 861177 flags 2
[29450.404959]          tree block backref root 2
[29450.404965]  item 2 key (503649550336 169 1) itemoff 3905 itemsize 33
[29450.404971]          extent refs 1 gen 861177 flags 2
[29450.404977]          tree block backref root 2
[29450.404984]  item 3 key (503649566720 169 0) itemoff 3872 itemsize 33
[29450.404991]          extent refs 1 gen 861177 flags 2
[29450.404996]          tree block backref root 2
[29450.405001]  item 4 key (503649570816 169 0) itemoff 3839 itemsize 33
[29450.405007]          extent refs 1 gen 861177 flags 2
[29450.405012]          tree block backref root 2
[29450.405019]  item 5 key (503649607680 169 0) itemoff 3806 itemsize 33
[29450.405025]          extent refs 1 gen 861177 flags 2
[29450.405028]          tree block backref root 2
[29450.405030]  item 6 key (503649628160 169 0) itemoff 3773 itemsize 33
[29450.405031]          extent refs 1 gen 861177 flags 2
[29450.405032]          tree block backref root 2
[29450.405034]  item 7 key (503649636352 169 0) itemoff 3740 itemsize 33
[29450.405036]          extent refs 1 gen 861177 flags 2
[29450.405037]          tree block backref root 2
[29450.405039]  item 8 key (503649669120 169 1) itemoff 3707 itemsize 33
[29450.405040]          extent refs 1 gen 861177 flags 2
[29450.405041]          tree block backref root 1
[29450.405043]  item 9 key (503649705984 169 0) itemoff 3674 itemsize 33
[29450.405045]          extent refs 1 gen 861177 flags 2
[29450.405046]          tree block backref root 1
[29450.405048]  item 10 key (950359621632 169 4) itemoff 3641 itemsize 33
[29450.405049]          extent refs 1 gen 861178 flags 2
[29450.405050]          tree block backref root 5
[29450.405053]  item 11 key (950359621632 192 1107296256) itemoff 3617 
itemsize 24
[29450.405054]          block group used 0
[29450.405056]  item 12 key (950359625728 169 3) itemoff 3584 itemsize 33
[29450.405057]          extent refs 1 gen 861178 flags 2
[29450.405058]          tree block backref root 5
[29450.405060]  item 13 key (950359629824 169 2) itemoff 3551 itemsize 33
[29450.405062]          extent refs 1 gen 861178 flags 2
[29450.405063]          tree block backref root 5
[29450.405065]  item 14 key (950359633920 169 1) itemoff 3518 itemsize 33
[29450.405067]          extent refs 1 gen 861178 flags 2
[29450.405067]          tree block backref root 5
[29450.405070]  item 15 key (950359638016 169 0) itemoff 3485 itemsize 33
[29450.405071]          extent refs 1 gen 861178 flags 2
[29450.405072]          tree block backref root 5
[29450.405074]  item 16 key (950359642112 169 1) itemoff 3452 itemsize 33
[29450.405076]          extent refs 1 gen 861178 flags 2
[29450.405077]          tree block backref root 5
[29450.405079]  item 17 key (950359646208 169 0) itemoff 3419 itemsize 33
[29450.405080]          extent refs 1 gen 861178 flags 2
[29450.405081]          tree block backref root 5
[29450.405083]  item 18 key (950359650304 169 3) itemoff 3386 itemsize 33
[29450.405085]          extent refs 1 gen 861178 flags 2
[29450.405086]          tree block backref root 5
[29450.405088]  item 19 key (950359654400 169 2) itemoff 3353 itemsize 33
[29450.405089]          extent refs 1 gen 861178 flags 2
[29450.405090]          tree block backref root 5
[29450.405093]  item 20 key (950359658496 169 1) itemoff 3320 itemsize 33
[29450.405094]          extent refs 1 gen 861178 flags 2
[29450.405095]          tree block backref root 5
[29450.405097]  item 21 key (950359662592 169 0) itemoff 3287 itemsize 33
[29450.405099]          extent refs 1 gen 861178 flags 2
[29450.405100]          tree block backref root 5
[29450.405102]  item 22 key (950359666688 169 1) itemoff 3254 itemsize 33
[29450.405103]          extent refs 1 gen 861178 flags 2
[29450.405104]          tree block backref root 5
[29450.405106]  item 23 key (950359670784 169 1) itemoff 3221 itemsize 33
[29450.405108]          extent refs 1 gen 861178 flags 2
[29450.405109]          tree block backref root 2
[29450.405111]  item 24 key (950359674880 169 0) itemoff 3188 itemsize 33
[29450.405112]          extent refs 1 gen 861178 flags 2
[29450.405113]          tree block backref root 5
[29450.405115]  item 25 key (950359678976 169 0) itemoff 3155 itemsize 33
[29450.405117]          extent refs 1 gen 861178 flags 2
[29450.405118]          tree block backref root 2
[29450.405120]  item 26 key (950359683072 169 1) itemoff 3122 itemsize 33
[29450.405122]          extent refs 1 gen 861178 flags 2
[29450.405123]          tree block backref root 5
[29450.405125]  item 27 key (950359687168 169 0) itemoff 3089 itemsize 33
[29450.405126]          extent refs 1 gen 861178 flags 2
[29450.405127]          tree block backref root 5
[29450.405129]  item 28 key (950359691264 169 1) itemoff 3056 itemsize 33
[29450.405131]          extent refs 1 gen 861178 flags 2
[29450.405132]          tree block backref root 5
[29450.405134]  item 29 key (950359695360 169 0) itemoff 3023 itemsize 33
[29450.405135]          extent refs 1 gen 861178 flags 2
[29450.405136]          tree block backref root 5
[29450.405138]  item 30 key (950359699456 169 2) itemoff 2990 itemsize 33
[29450.405140]          extent refs 1 gen 861178 flags 2
[29450.405141]          tree block backref root 5
[29450.405143]  item 31 key (950359703552 169 1) itemoff 2957 itemsize 33
[29450.405144]          extent refs 1 gen 861178 flags 2
[29450.405145]          tree block backref root 5
[29450.405148]  item 32 key (951466917888 192 1107296256) itemoff 2933 
itemsize 24
[29450.405149]          block group used 0
[29450.405151]  item 33 key (952574214144 192 100663296) itemoff 2909 itemsize 
24
[29450.405152]          block group used 0
[29450.405154]  item 34 key (952674877440 192 3221225472) itemoff 2885 
itemsize 24
[29450.405155]          block group used 0
[29450.405157]  item 35 key (955896102912 192 3221225472) itemoff 2861 
itemsize 24
[29450.405158]          block group used 0
[29450.405160]  item 36 key (959117328384 192 3221225472) itemoff 2837 
itemsize 24
[29450.405161]          block group used 0
[29450.405163]  item 37 key (962338553856 192 3221225472) itemoff 2813 
itemsize 24
[29450.405164]          block group used 0
[29450.405166]  item 38 key (965559779328 192 3221225472) itemoff 2789 
itemsize 24
[29450.405167]          block group used 0
[29450.405169]  item 39 key (968781004800 192 3221225472) itemoff 2765 
itemsize 24
[29450.405171]          block group used 0
[29450.405173]  item 40 key (972002230272 192 3221225472) itemoff 2741 
itemsize 24
[29450.405174]          block group used 0
[29450.405176]  item 41 key (975223455744 192 3221225472) itemoff 2717 
itemsize 24
[29450.405177]          block group used 0
[29450.405179]  item 42 key (978444681216 192 3221225472) itemoff 2693 
itemsize 24
[29450.405180]          block group used 0
[29450.405182]  item 43 key (981665906688 192 3221225472) itemoff 2669 
itemsize 24
[29450.405183]          block group used 0
[29450.405185]  item 44 key (984887132160 192 3221225472) itemoff 2645 
itemsize 24
[29450.405186]          block group used 0
[29450.405188]  item 45 key (988108357632 192 3221225472) itemoff 2621 
itemsize 24
[29450.405189]          block group used 0
[29450.405191]  item 46 key (991329583104 192 3221225472) itemoff 2597 
itemsize 24
[29450.405192]          block group used 0
[29450.405194]  item 47 key (994550808576 192 3221225472) itemoff 2573 
itemsize 24
[29450.405195]          block group used 0
[29450.405197]  item 48 key (997772034048 192 3221225472) itemoff 2549 
itemsize 24
[29450.405198]          block group used 0
[29450.405200]  item 49 key (1000993259520 192 3221225472) itemoff 2525 
itemsize 24
[29450.405201]          block group used 0
[29450.405204]  item 50 key (1004214484992 192 3221225472) itemoff 2501 
itemsize 24
[29450.405205]          block group used 0
[29450.405207]  item 51 key (1007435710464 192 3221225472) itemoff 2477 
itemsize 24
[29450.405208]          block group used 0
[29450.405210]  item 52 key (1010656935936 192 3221225472) itemoff 2453 
itemsize 24
[29450.405211]          block group used 0
[29450.405213]  item 53 key (1013878161408 192 3221225472) itemoff 2429 
itemsize 24
[29450.405214]          block group used 0
[29450.405216]  item 54 key (1017099386880 192 3221225472) itemoff 2405 
itemsize 24
[29450.405217]          block group used 0
[29450.405219]  item 55 key (1020320612352 192 3221225472) itemoff 2381 
itemsize 24
[29450.405220]          block group used 0
[29450.405222]  item 56 key (1023541837824 192 3221225472) itemoff 2357 
itemsize 24
[29450.405223]          block group used 0
[29450.405225]  item 57 key (1026763063296 192 3221225472) itemoff 2333 
itemsize 24
[29450.405228]          block group used 0
[29450.405232]  item 58 key (1029984288768 192 3221225472) itemoff 2309 
itemsize 24
[29450.405237]          block group used 0
[29450.405241]  item 59 key (1033205514240 192 3221225472) itemoff 2285 
itemsize 24
[29450.405244]          block group used 0
[29450.405250]  item 60 key (1036426739712 192 3221225472) itemoff 2261 
itemsize 24
[29450.405255]          block group used 0
[29450.405262]  item 61 key (1039647965184 192 3221225472) itemoff 2237 
itemsize 24
[29450.405266]          block group used 0
[29450.405272]  item 62 key (1042869190656 192 3221225472) itemoff 2213 
itemsize 24
[29450.405279]          block group used 0
[29450.405288]  item 63 key (1046090416128 192 3221225472) itemoff 2189 
itemsize 24
[29450.405293]          block group used 0
[29450.405297]  item 64 key (1049311641600 192 3221225472) itemoff 2165 
itemsize 24
[29450.405304]          block group used 0
[29450.405310]  item 65 key (1052532867072 192 3221225472) itemoff 2141 
itemsize 24
[29450.405317]          block group used 0
[29450.405323]  item 66 key (1055754092544 192 3221225472) itemoff 2117 
itemsize 24
[29450.405329]          block group used 0
[29450.405335] BTRFS error (device sdd): unable to find ref byte nr 
951595991040 parent 0 root 5  owner 1 offset 0
[29450.405350] BTRFS: error (device sdd) in __btrfs_free_extent:6951: errno=-2 
No such entry
[29450.405373] BTRFS: error (device sdd) in btrfs_run_delayed_refs:2960: 
errno=-2 No such entry
[29450.406872] pending csums is 4096


btrfs output:
root@dibsi:/home/jan# btrfs check /dev/disk/by-uuid/
73d4dc77-6ff3-412f-9b0a-0d11458faf32 
Checking filesystem on /dev/disk/by-uuid/73d4dc77-6ff3-412f-9b0a-0d11458faf32
UUID: 73d4dc77-6ff3-412f-9b0a-0d11458faf32
checking extents
parent transid verify failed on 2280458502144 wanted 861168 found 860380
parent transid verify failed on 2280458502144 wanted 861168 found 860380
checksum verify failed on 2280458502144 found FC3DF84D wanted 2164EB93
checksum verify failed on 2280458502144 found FC3DF84D wanted 2164EB93
bytenr mismatch, want=2280458502144, have=15938383240448
parent transid verify failed on 2280458502144 wanted 861168 found 860380
parent transid verify failed on 2280458502144 wanted 861168 found 860380
checksum verify failed on 2280458502144 found FC3DF84D wanted 2164EB93
checksum verify failed on 2280458502144 found FC3DF84D wanted 2164EB93
bytenr mismatch, want=2280458502144, have=15938383240448
parent transid verify failed on 2280458506240 wanted 861168 found 860380
parent transid verify failed on 2280458506240 wanted 861168 found 860380
checksum verify failed on 2280458506240 found E76FAE4B wanted 968BCF7A
checksum verify failed on 2280458506240 found E76FAE4B wanted 968BCF7A
bytenr mismatch, want=2280458506240, have=15938383228160
parent transid verify failed on 2280458510336 wanted 861168 found 860380
parent transid verify failed on 2280458510336 wanted 861168 found 860380
checksum verify failed on 2280458510336 found ABA824E6 wanted FD072FC5
checksum verify failed on 2280458510336 found ABA824E6 wanted FD072FC5
bytenr mismatch, want=2280458510336, have=15938383199488
parent transid verify failed on 2280458620928 wanted 861168 found 860380
parent transid verify failed on 2280458620928 wanted 861168 found 860380
checksum verify failed on 2280458620928 found 4C43E476 wanted F3660326
checksum verify failed on 2280458620928 found 4C43E476 wanted F3660326
bytenr mismatch, want=2280458620928, have=15938383802368
parent transid verify failed on 2280458625024 wanted 861168 found 860380
parent transid verify failed on 2280458625024 wanted 861168 found 860380
checksum verify failed on 2280458625024 found AD8EE78F wanted 093A4586
checksum verify failed on 2280458625024 found AD8EE78F wanted 093A4586
bytenr mismatch, want=2280458625024, have=15938383831040
parent transid verify failed on 2280458629120 wanted 861168 found 860380
parent transid verify failed on 2280458629120 wanted 861168 found 860380
checksum verify failed on 2280458629120 found 67FC5731 wanted 3F68DF37
checksum verify failed on 2280458629120 found 67FC5731 wanted 3F68DF37
bytenr mismatch, want=2280458629120, have=15938383810560
parent transid verify failed on 2280458633216 wanted 861168 found 860380
parent transid verify failed on 2280458633216 wanted 861168 found 860380
checksum verify failed on 2280458633216 found D3E6B383 wanted 372BEB16
checksum verify failed on 2280458633216 found D3E6B383 wanted 372BEB16
bytenr mismatch, want=2280458633216, have=15938383830272
parent transid verify failed on 2280458637312 wanted 861168 found 860380
parent transid verify failed on 2280458637312 wanted 861168 found 860380
checksum verify failed on 2280458637312 found AD56590B wanted 27275E35
checksum verify failed on 2280458637312 found AD56590B wanted 27275E35
bytenr mismatch, want=2280458637312, have=15938383817984
parent transid verify failed on 2280458645504 wanted 861168 found 860380
parent transid verify failed on 2280458645504 wanted 861168 found 860380
checksum verify failed on 2280458645504 found 609E8D90 wanted 62B88736
checksum verify failed on 2280458645504 found 609E8D90 wanted 62B88736
bytenr mismatch, want=2280458645504, have=15938383793408
parent transid verify failed on 2280465395712 wanted 861168 found 860380
parent transid verify failed on 2280465395712 wanted 861168 found 860380
checksum verify failed on 2280465395712 found 1EE17660 wanted 5A593448
checksum verify failed on 2280465395712 found 1EE17660 wanted 5A593448
bytenr mismatch, want=2280465395712, have=15938501561600
parent transid verify failed on 2280415236096 wanted 861168 found 860380
parent transid verify failed on 2280415236096 wanted 861168 found 860380
checksum verify failed on 2280415236096 found F04B13C4 wanted CD1F2721
checksum verify failed on 2280415236096 found F04B13C4 wanted CD1F2721
bytenr mismatch, want=2280415236096, have=15938149183488
parent transid verify failed on 2280259969024 wanted 861166 found 860373
parent transid verify failed on 2280259969024 wanted 861166 found 860373
checksum verify failed on 2280259969024 found B80076DB wanted 09C8FA6F
checksum verify failed on 2280259969024 found B80076DB wanted 09C8FA6F
bytenr mismatch, want=2280259969024, have=15937221663232
parent transid verify failed on 2280409526272 wanted 861168 found 860376
parent transid verify failed on 2280409526272 wanted 861168 found 860376
checksum verify failed on 2280409526272 found 4357A5F3 wanted 969A158E
checksum verify failed on 2280409526272 found 4357A5F3 wanted 969A158E
bytenr mismatch, want=2280409526272, have=15938088724992
parent transid verify failed on 2280428298240 wanted 861168 found 860376
parent transid verify failed on 2280428298240 wanted 861168 found 860376
checksum verify failed on 2280428298240 found B8F51F6A wanted A2F455BD
checksum verify failed on 2280428298240 found B8F51F6A wanted A2F455BD
bytenr mismatch, want=2280428298240, have=15938466364672
parent transid verify failed on 2280446873600 wanted 861168 found 860380
parent transid verify failed on 2280446873600 wanted 861168 found 860380
checksum verify failed on 2280446873600 found DDD2FE66 wanted F89EED66
checksum verify failed on 2280446873600 found DDD2FE66 wanted F89EED66
bytenr mismatch, want=2280446873600, have=15938382596608
parent transid verify failed on 2280272723968 wanted 861166 found 860370
parent transid verify failed on 2280272723968 wanted 861166 found 860370
checksum verify failed on 2280272723968 found E4F93095 wanted B089A4B7
checksum verify failed on 2280272723968 found E4F93095 wanted B089A4B7
bytenr mismatch, want=2280272723968, have=15937216620288
parent transid verify failed on 2280345731072 wanted 861168 found 860377
parent transid verify failed on 2280345731072 wanted 861168 found 860377
checksum verify failed on 2280345731072 found 316EB1A6 wanted 1249429F
checksum verify failed on 2280345731072 found 316EB1A6 wanted 1249429F
bytenr mismatch, want=2280345731072, have=15937407592192
parent transid verify failed on 2280347447296 wanted 861167 found 860377
parent transid verify failed on 2280347447296 wanted 861167 found 860377
checksum verify failed on 2280347447296 found 6D4A46D8 wanted F2C503E1
checksum verify failed on 2280347447296 found 6D4A46D8 wanted F2C503E1
bytenr mismatch, want=2280347447296, have=15937414706944
parent transid verify failed on 2280388960256 wanted 861168 found 860380
parent transid verify failed on 2280388960256 wanted 861168 found 860380
checksum verify failed on 2280388960256 found 3B3067A0 wanted 46EE075B
checksum verify failed on 2280388960256 found 3B3067A0 wanted 46EE075B
bytenr mismatch, want=2280388960256, have=15938310299648
parent transid verify failed on 2280389693440 wanted 861168 found 860380
parent transid verify failed on 2280389693440 wanted 861168 found 860380
checksum verify failed on 2280389693440 found FABC36B0 wanted E26236B9
checksum verify failed on 2280389693440 found FABC36B0 wanted E26236B9
bytenr mismatch, want=2280389693440, have=15938306026752
parent transid verify failed on 2280157011968 wanted 861165 found 860361
parent transid verify failed on 2280157011968 wanted 861165 found 860361
checksum verify failed on 2280157011968 found 40E10FA2 wanted FF1F5A65
checksum verify failed on 2280157011968 found 40E10FA2 wanted FF1F5A65
bytenr mismatch, want=2280157011968, have=15936811604480
parent transid verify failed on 2280157970432 wanted 861165 found 860361
parent transid verify failed on 2280157970432 wanted 861165 found 860361
checksum verify failed on 2280157970432 found 331A4EF6 wanted 6D271A13
checksum verify failed on 2280157970432 found 331A4EF6 wanted 6D271A13
bytenr mismatch, want=2280157970432, have=15936577447680
parent transid verify failed on 2280427163648 wanted 861168 found 860380
parent transid verify failed on 2280427163648 wanted 861168 found 860380
checksum verify failed on 2280427163648 found 1C8FE3B6 wanted 95818BD4
checksum verify failed on 2280427163648 found 1C8FE3B6 wanted 95818BD4
bytenr mismatch, want=2280427163648, have=15938458906624
parent transid verify failed on 2280445718528 wanted 861168 found 860380
parent transid verify failed on 2280445718528 wanted 861168 found 860380
checksum verify failed on 2280445718528 found 67E355D6 wanted B49E524F
checksum verify failed on 2280445718528 found 67E355D6 wanted B49E524F
bytenr mismatch, want=2280445718528, have=15938385121280
parent transid verify failed on 503649468416 wanted 2486 found 861173
Ignoring transid failure
parent transid verify failed on 503649472512 wanted 2486 found 861177
parent transid verify failed on 503649472512 wanted 2486 found 861177
checksum verify failed on 503649472512 found 094AA6E5 wanted 76FAADD7
checksum verify failed on 503649472512 found 094AA6E5 wanted 76FAADD7
bytenr mismatch, want=503649472512, have=372927852544
parent transid verify failed on 503649476608 wanted 818691 found 861177
parent transid verify failed on 503649476608 wanted 818691 found 861177
checksum verify failed on 503649476608 found 6CF07DA7 wanted 1EC02B4E
checksum verify failed on 503649476608 found 6CF07DA7 wanted 1EC02B4E
bytenr mismatch, want=503649476608, have=372927881216
parent transid verify failed on 503649480704 wanted 2486 found 861177
parent transid verify failed on 503649480704 wanted 2486 found 861177
checksum verify failed on 503649480704 found 74888BDC wanted 5396C8AC
bytenr mismatch, want=503649480704, have=503649415168
parent transid verify failed on 503649484800 wanted 141269 found 861172
parent transid verify failed on 503649484800 wanted 141269 found 861172
checksum verify failed on 503649484800 found 519C3303 wanted 1B4232A5
checksum verify failed on 503649484800 found 519C3303 wanted 1B4232A5
bytenr mismatch, want=503649484800, have=372927880448
parent transid verify failed on 503649488896 wanted 2486 found 861176
parent transid verify failed on 503649488896 wanted 2486 found 861176
checksum verify failed on 503649488896 found 4619DDAF wanted A0B78F95
bytenr mismatch, want=503649488896, have=503649423360
parent transid verify failed on 503649492992 wanted 2486 found 861176
parent transid verify failed on 503649492992 wanted 2486 found 861176
checksum verify failed on 503649492992 found EBC18A42 wanted F05DA8AA
bytenr mismatch, want=503649492992, have=503649427456
parent transid verify failed on 503649497088 wanted 2486 found 861176
parent transid verify failed on 503649497088 wanted 2486 found 861176
checksum verify failed on 503649497088 found B046E5A0 wanted 9867B21F
checksum verify failed on 503649497088 found B046E5A0 wanted 9867B21F
bytenr mismatch, want=503649497088, have=372927843584
parent transid verify failed on 503649501184 wanted 2486 found 861176
parent transid verify failed on 503649501184 wanted 2486 found 861176
checksum verify failed on 503649501184 found 717EBF4C wanted A15FDF58
parent transid verify failed on 503649501184 wanted 2486 found 861176
Ignoring transid failure
leaf parent key incorrect 503649501184
bad block 503649501184
ERROR: errors found in extent allocation tree or chunk allocation
parent transid verify failed on 2280458502144 wanted 861168 found 860380
parent transid verify failed on 2280458502144 wanted 861168 found 860380
checksum verify failed on 2280458502144 found FC3DF84D wanted 2164EB93
checksum verify failed on 2280458502144 found FC3DF84D wanted 2164EB93
bytenr mismatch, want=2280458502144, have=15938383240448

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: mounting failed any file on my filesystem
  2016-12-29 19:05 mounting failed any file on my filesystem Jan Koester
@ 2016-12-29 22:31 ` Duncan
  2016-12-30 12:17   ` Jan Koester
  0 siblings, 1 reply; 5+ messages in thread
From: Duncan @ 2016-12-29 22:31 UTC (permalink / raw)
  To: linux-btrfs

Jan Koester posted on Thu, 29 Dec 2016 20:05:35 +0100 as excerpted:

> Hi,
> 
> i have problem with filesystem if my system crashed i have made been
> hard reset of the system after my Filesystem was crashed. I have already
> tried to repair without success you can see it on log file. It's seem
> one corrupted block brings complete filesystem to crashing.
> 
> Have anybody idea what happened with my filesystem ?
> 
> dmesg if open file:
> [29450.404327] WARNING: CPU: 5 PID: 16161 at
> /build/linux-lIgGMF/linux-4.8.11/ fs/btrfs/extent-tree.c:6945
> __btrfs_free_extent.isra.71+0x8e2/0xd60 [btrfs]

First a disclaimer.  I'm a btrfs user and list regular, not a dev.  As 
such I don't really read call traces much beyond checking the kernel 
version, and don't do code.  It's likely that you will get a more 
authoritative reply from someone who does, and it should take precedence, 
but in the mean time, I can try to deal with the preliminaries.

Kernel 4.8.11, good.  But you run btrfs check below, and we don't have 
the version of your btrfs-progs userspace.  Please report that too.

> btrfs output:
> root@dibsi:/home/jan# btrfs check /dev/disk/by-uuid/
> 73d4dc77-6ff3-412f-9b0a-0d11458faf32

Note that btrfs check is read-only by default.  It will report what it 
thinks are errors, but won't attempt to fix them unless you add various 
options (such as --repair) to tell it to do so.  This is by design and is 
very important, as attempting to repair problems that it doesn't properly 
understand could make the problems worse instead of better.  So even tho 
the above command will only report what it sees as problems, not attempt 
to fix them, you did the right thing by running check without --repair 
first, and posting the results here for an expert to look at and tell you 
whether to try --repair, or what else to try instead.

> Checking filesystem on
> /dev/disk/by-uuid/73d4dc77-6ff3-412f-9b0a-0d11458faf32
> UUID: 73d4dc77-6ff3-412f-9b0a-0d11458faf32
> checking extents
> parent transid verify failed on 2280458502144 wanted 861168
> found 860380
> parent transid verify failed on 2280458502144 wanted 861168
> found 860380
> checksum verify failed on 2280458502144 found FC3DF84D
> wanted 2164EB93
> checksum verify failed on 2280458502144 found FC3DF84D
> wanted 2164EB93
> bytenr mismatch, want=2280458502144, have=15938383240448
[...]

Some other information that we normally ask for includes the output from 
a few other btrfs commands.

It's unclear from your report if the filesystem will mount at all.  The 
subject says mount failed, but then it mentions any file on the 
filesystem, which seems to imply that you could mount, but that any file 
you attempted to actually access after mounting crashes the system with 
the trace you posted, so I'm not sure if you can actually mount the 
filesystem at all.

If you can't mount the filesystem, at least try to post the output from...

btrfs filesystem show

If you can mount the filesystem, then the much more detailed...

btrfs filesystem usage

... if your btrfs-progs is new enough, or...

btrfs filesystem df

... if btrfs-progs is too old to have the usage command.

Also, if it's not clear from the output of the commands above (usage by 
itself, or show plus df, should answer most of the below, but show alone 
only provides some of the information), tell us a bit more about the 
filesystem in question:

Single device (like traditional filesystems) or multiple device?  If 
multiple device, what raid levels if you know them, or did you just go 
with the defaults.  If single device, again, defaults, or did you specify 
single or dup, particularly for metadata.

Also, how big was the filesystem and how close to full?  And was it on 
ssd, spinning rust, or on top of something virtual (like a VM image 
existing as a file on the host, or lvm, or mdraid, etc)?


Meanwhile, if you can mount, the first thing I'd try is btrfs scrub 
(unless you were running btrfs raid56 mode, which makes things far more 
complex as it's not stable yet and isn't recommended except for testing 
with data you can afford to lose).  Often, a scrub can fix much of the 
damage of a crash if you were running raid1 mode (multi-device metadata 
default), raid10, or dup (single device metadata default, except on ssd), 
as those have a second checksummed copy that will often be correct that 
scrub can use to fix the bad copy, but it will detect but be unable to 
fix damage in single mode (default for data) or raid0 mode, as those 
don't have a second copy available to fix the first.

Because the default for single device btrfs is dup metadata, single data, 
in that case the scrub should fix most or all of metadata, allowing you 
to access small file (roughly anything under a couple KiB) and larger 
files that weren't themselves damaged, but you may still have damage in 
some files of any significant size.

But scrub can only run if you can mount the filesystem.  If you can't, 
then you have to try other things in ordered to get it mountable, first.  
Many of these other things tend to be much more complex and risky, so if 
you can mount at all, try scrub first, and see how much it helps.  Here 
I'm dual-device raid1 for nearly all my btrfs, and (assuming I can mount 
the affected filesystem, which I usually can) I now run scrub first thing 
after a crash, as a preventative measure even without knowing if the 
filesystem was damaged or not.

If the filesystem won't mount, then the recommendation is /likely/ to be 
trying the usebackuproot mount option (which replaced the older recovery 
mount option, but you're using a new enough kernel for usebackuproot), 
which will try some older tree roots if the newest one is damaged.  You 
may have to use that option with readonly, which of course will prevent 
running scrub or the like while mounted, but may help you get access to 
the data at least to freshen up your backups.  However, usebackuproot 
will by definition sacrifice the last seconds of writes before the crash, 
and while I'd probably try this option on my own system without asking, 
I'm not comfortable recommending it to others, so I'd suggest waiting for 
one of the higher experts to confirm, before trying it yourself.

Beyond usebackuproot, you get into more risky attempts to repair that may 
instead do further damage if they don't work.  This is where btrfs check 
--repair lives, along with some other check options, btrfs rescue, etc.  
Unless specifically told otherwise by an expert after they look at the 
filesystem info, these are risky enough that if at all possible, you want 
to freshen your backups before you try them.

That's where btrfs restore comes in, as it lets you try to attempt 
restoring files from an unmountable filesystem, while not actually 
writing to that filesystem, thus not risking doing further damage, in the 
process.  Of course that means you have to have some place to put the 
files it's going to restore.  In simple mode you just run btrfs restore 
with commandline parameters telling it what device to try to restore from 
and where to put the restored files (and some options telling it whether 
to try restoring metadata like file ownership, permissions, dates, etc), 
and it just works.

However, should btrfs restore's simple mode fail, there's more complex 
advanced modes to try, still without risking further damage to the 
filesystem in question, but that gets complex enough it needs its own 
post... if you come to that.  There's a page on the wiki with some 
instructions, but they may not be current and it's a complex enough 
operation that most people need help beyond what's on the wiki (and in 
the btrfs-restore manpage), anyway.  But here's the link so you can take 
a look at what the general operation looks like:

https://btrfs.wiki.kernel.org/index.php/Restore

Meanwhile, it's a bit late now, but in general, btrfs is considered still 
in heavy development, stabilizing but not yet fully stable and mature.  
As such, while any sysadmin worth the label will tell you that you are 
defining any data you don't have backups for as not worth the time, 
trouble and resources to do those backups, basically defining it as throw-
away data because it's /not/ worth backing up or by definition you'd 
/have/ those backups, even for normal stable and mature filesystems, with 
btrfs still stabilizing, backups are even /more/ strongly recommended, as 
is keeping them current within the window of data you're willing to lose 
if you lose the primary copy, and keeping those backups practically 
usable (not over a slow net link that'll take over a week to download in 
ordered to restore, for instance, one real case that was posted).  If 
you're doing that then losing a filesystem isn't going to be a big stress 
and you can afford to skip the real complex and risky stuff (unless 
you're simply doing it to learn how) and just restore from backup, as it 
will be simpler.  If not, then you should really reexamine whether btrfs 
is the right filesystem choice for you, because it /isn't/ yet fully 
stable and mature, and chances are you'd be better off with a more stable 
and mature filesystem where not having updated at-hand backups is less of 
a risk (altho as I said any sysadmin worth the name will tell you not 
having backups is literally defining the data as throw-away value, 
because in the real world, "things happen", and there's too many of those 
things possible in the real world to behave otherwise).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: mounting failed any file on my filesystem
  2016-12-29 22:31 ` Duncan
@ 2016-12-30 12:17   ` Jan Koester
  2016-12-31  5:05     ` Duncan
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Koester @ 2016-12-30 12:17 UTC (permalink / raw)
  To: Duncan; +Cc: linux-btrfs

On Donnerstag, 29. Dezember 2016 22:31:29 CET Duncan wrote:
> Jan Koester posted on Thu, 29 Dec 2016 20:05:35 +0100 as excerpted:
> > Hi,
> > 
> > i have problem with filesystem if my system crashed i have made been
> > hard reset of the system after my Filesystem was crashed. I have already
> > tried to repair without success you can see it on log file. It's seem
> > one corrupted block brings complete filesystem to crashing.
> > 
> > Have anybody idea what happened with my filesystem ?
> > 
> > dmesg if open file:
> > [29450.404327] WARNING: CPU: 5 PID: 16161 at
> > /build/linux-lIgGMF/linux-4.8.11/ fs/btrfs/extent-tree.c:6945
> > __btrfs_free_extent.isra.71+0x8e2/0xd60 [btrfs]
> 
> First a disclaimer.  I'm a btrfs user and list regular, not a dev.  As
> such I don't really read call traces much beyond checking the kernel
> version, and don't do code.  It's likely that you will get a more
> authoritative reply from someone who does, and it should take precedence,
> but in the mean time, I can try to deal with the preliminaries.
> 
> Kernel 4.8.11, good.  But you run btrfs check below, and we don't have
> the version of your btrfs-progs userspace.  Please report that too.
> 
> > btrfs output:
> > root@dibsi:/home/jan# btrfs check /dev/disk/by-uuid/
> > 73d4dc77-6ff3-412f-9b0a-0d11458faf32
> 
> Note that btrfs check is read-only by default.  It will report what it
> thinks are errors, but won't attempt to fix them unless you add various
> options (such as --repair) to tell it to do so.  This is by design and is
> very important, as attempting to repair problems that it doesn't properly
> understand could make the problems worse instead of better.  So even tho
> the above command will only report what it sees as problems, not attempt
> to fix them, you did the right thing by running check without --repair
> first, and posting the results here for an expert to look at and tell you
> whether to try --repair, or what else to try instead.
> 
> > Checking filesystem on
> > /dev/disk/by-uuid/73d4dc77-6ff3-412f-9b0a-0d11458faf32
> > UUID: 73d4dc77-6ff3-412f-9b0a-0d11458faf32
> > checking extents
> > parent transid verify failed on 2280458502144 wanted 861168
> > found 860380
> > parent transid verify failed on 2280458502144 wanted 861168
> > found 860380
> > checksum verify failed on 2280458502144 found FC3DF84D
> > wanted 2164EB93
> > checksum verify failed on 2280458502144 found FC3DF84D
> > wanted 2164EB93
> > bytenr mismatch, want=2280458502144, have=15938383240448
> 
> [...]
> 
> Some other information that we normally ask for includes the output from
> a few other btrfs commands.
> 
> It's unclear from your report if the filesystem will mount at all.  The
> subject says mount failed, but then it mentions any file on the
> filesystem, which seems to imply that you could mount, but that any file
> you attempted to actually access after mounting crashes the system with
> the trace you posted, so I'm not sure if you can actually mount the
> filesystem at all.
> 
> If you can't mount the filesystem, at least try to post the output from...
> 
> btrfs filesystem show
> 
> If you can mount the filesystem, then the much more detailed...
> 
> btrfs filesystem usage
> 
> ... if your btrfs-progs is new enough, or...
> 
> btrfs filesystem df
> 
> ... if btrfs-progs is too old to have the usage command.
> 
> Also, if it's not clear from the output of the commands above (usage by
> itself, or show plus df, should answer most of the below, but show alone
> only provides some of the information), tell us a bit more about the
> filesystem in question:
> 
> Single device (like traditional filesystems) or multiple device?  If
> multiple device, what raid levels if you know them, or did you just go
> with the defaults.  If single device, again, defaults, or did you specify
> single or dup, particularly for metadata.
> 
> Also, how big was the filesystem and how close to full?  And was it on
> ssd, spinning rust, or on top of something virtual (like a VM image
> existing as a file on the host, or lvm, or mdraid, etc)?
> 
> 
> Meanwhile, if you can mount, the first thing I'd try is btrfs scrub
> (unless you were running btrfs raid56 mode, which makes things far more
> complex as it's not stable yet and isn't recommended except for testing
> with data you can afford to lose).  Often, a scrub can fix much of the
> damage of a crash if you were running raid1 mode (multi-device metadata
> default), raid10, or dup (single device metadata default, except on ssd),
> as those have a second checksummed copy that will often be correct that
> scrub can use to fix the bad copy, but it will detect but be unable to
> fix damage in single mode (default for data) or raid0 mode, as those
> don't have a second copy available to fix the first.
> 
> Because the default for single device btrfs is dup metadata, single data,
> in that case the scrub should fix most or all of metadata, allowing you
> to access small file (roughly anything under a couple KiB) and larger
> files that weren't themselves damaged, but you may still have damage in
> some files of any significant size.
> 
> But scrub can only run if you can mount the filesystem.  If you can't,
> then you have to try other things in ordered to get it mountable, first.
> Many of these other things tend to be much more complex and risky, so if
> you can mount at all, try scrub first, and see how much it helps.  Here
> I'm dual-device raid1 for nearly all my btrfs, and (assuming I can mount
> the affected filesystem, which I usually can) I now run scrub first thing
> after a crash, as a preventative measure even without knowing if the
> filesystem was damaged or not.
> 
> If the filesystem won't mount, then the recommendation is /likely/ to be
> trying the usebackuproot mount option (which replaced the older recovery
> mount option, but you're using a new enough kernel for usebackuproot),
> which will try some older tree roots if the newest one is damaged.  You
> may have to use that option with readonly, which of course will prevent
> running scrub or the like while mounted, but may help you get access to
> the data at least to freshen up your backups.  However, usebackuproot
> will by definition sacrifice the last seconds of writes before the crash,
> and while I'd probably try this option on my own system without asking,
> I'm not comfortable recommending it to others, so I'd suggest waiting for
> one of the higher experts to confirm, before trying it yourself.
> 
> Beyond usebackuproot, you get into more risky attempts to repair that may
> instead do further damage if they don't work.  This is where btrfs check
> --repair lives, along with some other check options, btrfs rescue, etc.
> Unless specifically told otherwise by an expert after they look at the
> filesystem info, these are risky enough that if at all possible, you want
> to freshen your backups before you try them.
> 
> That's where btrfs restore comes in, as it lets you try to attempt
> restoring files from an unmountable filesystem, while not actually
> writing to that filesystem, thus not risking doing further damage, in the
> process.  Of course that means you have to have some place to put the
> files it's going to restore.  In simple mode you just run btrfs restore
> with commandline parameters telling it what device to try to restore from
> and where to put the restored files (and some options telling it whether
> to try restoring metadata like file ownership, permissions, dates, etc),
> and it just works.
> 
> However, should btrfs restore's simple mode fail, there's more complex
> advanced modes to try, still without risking further damage to the
> filesystem in question, but that gets complex enough it needs its own
> post... if you come to that.  There's a page on the wiki with some
> instructions, but they may not be current and it's a complex enough
> operation that most people need help beyond what's on the wiki (and in
> the btrfs-restore manpage), anyway.  But here's the link so you can take
> a look at what the general operation looks like:
> 
> https://btrfs.wiki.kernel.org/index.php/Restore
> 
> Meanwhile, it's a bit late now, but in general, btrfs is considered still
> in heavy development, stabilizing but not yet fully stable and mature.
> As such, while any sysadmin worth the label will tell you that you are
> defining any data you don't have backups for as not worth the time,
> trouble and resources to do those backups, basically defining it as throw-
> away data because it's /not/ worth backing up or by definition you'd
> /have/ those backups, even for normal stable and mature filesystems, with
> btrfs still stabilizing, backups are even /more/ strongly recommended, as
> is keeping them current within the window of data you're willing to lose
> if you lose the primary copy, and keeping those backups practically
> usable (not over a slow net link that'll take over a week to download in
> ordered to restore, for instance, one real case that was posted).  If
> you're doing that then losing a filesystem isn't going to be a big stress
> and you can afford to skip the real complex and risky stuff (unless
> you're simply doing it to learn how) and just restore from backup, as it
> will be simpler.  If not, then you should really reexamine whether btrfs
> is the right filesystem choice for you, because it /isn't/ yet fully
> stable and mature, and chances are you'd be better off with a more stable
> and mature filesystem where not having updated at-hand backups is less of
> a risk (altho as I said any sysadmin worth the name will tell you not
> having backups is literally defining the data as throw-away value,
> because in the real world, "things happen", and there's too many of those
> things possible in the real world to behave otherwise).

hi,

I'am using kernel 4.8.0-2 and btrfsprogs 4.9.

I can mouting now the filesystem but it's chrashed when i try to access file on 
this filesystem.

btrfs fi show
Label: none  uuid: 73d4dc77-6ff3-412f-9b0a-0d11458faf32
        Total devices 5 FS bytes used 1.17TiB
        devid    1 size 931.51GiB used 420.78GiB path /dev/sdd
        devid    2 size 931.51GiB used 420.78GiB path /dev/sdf
        devid    3 size 931.51GiB used 420.78GiB path /dev/sde
        devid    4 size 931.51GiB used 420.78GiB path /dev/sda
        devid    5 size 931.51GiB used 420.78GiB path /dev/sdc

btrfs filesystem usage

sudo btrfs filesystem usage /mnt
WARNING: RAID56 detected, not implemented
WARNING: RAID56 detected, not implemented
WARNING: RAID56 detected, not implemented
Overall:
    Device size:                   4.55TiB
    Device allocated:                0.00B
    Device unallocated:            4.55TiB
    Device missing:                  0.00B
    Used:                            0.00B
    Free (estimated):                0.00B      (min: 8.00EiB)
    Data ratio:                       0.00
    Metadata ratio:                   0.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID6: Size:1.22TiB, Used:0.00B
   /dev/sda      418.00GiB
   /dev/sdc      418.00GiB
   /dev/sdd      418.00GiB
   /dev/sde      418.00GiB
   /dev/sdf      418.00GiB

Metadata,RAID6: Size:8.25GiB, Used:44.00KiB
   /dev/sda        2.75GiB
   /dev/sdc        2.75GiB
   /dev/sdd        2.75GiB
   /dev/sde        2.75GiB
   /dev/sdf        2.75GiB

System,RAID6: Size:96.00MiB, Used:0.00B
   /dev/sda       32.00MiB
   /dev/sdc       32.00MiB
   /dev/sdd       32.00MiB
   /dev/sde       32.00MiB
   /dev/sdf       32.00MiB

Unallocated:
   /dev/sda      510.73GiB
   /dev/sdc      510.73GiB
   /dev/sdd      510.73GiB
   /dev/sde      510.73GiB
   /dev/sdf      510.73GiB


sudo btrfs filesystem df /mnt
Data, RAID6: total=1.22TiB, used=0.00B
System, RAID6: total=96.00MiB, used=0.00B
Metadata, RAID6: total=8.25GiB, used=80.00KiB
GlobalReserve, single: total=512.00MiB, used=8.00KiB



^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: mounting failed any file on my filesystem
  2016-12-30 12:17   ` Jan Koester
@ 2016-12-31  5:05     ` Duncan
  2017-01-01 17:24       ` Jan Koester
  0 siblings, 1 reply; 5+ messages in thread
From: Duncan @ 2016-12-31  5:05 UTC (permalink / raw)
  To: linux-btrfs

Jan Koester posted on Fri, 30 Dec 2016 13:17:37 +0100 as excerpted:

> sudo btrfs filesystem df /mnt
> Data, RAID6: total=1.22TiB, used=0.00B
> System, RAID6: total=96.00MiB, used=0.00B
> Metadata, RAID6: total=8.25GiB, used=80.00KiB
> GlobalReserve, single: total=512.00MiB, used=8.00KiB

Expanding on what I already mentioned in passing (hoping it wasn't the 
case), raid56 mode (so including your raid6) remains quite unstable, with 
known problems that make it unsuitable for the sort of purposes people 
normally run parity-raid for.  So it's actively negatively recommended 
unless you're running it for the specific purpose of trying to help the 
devs work out the problems with it, using only throw-away-value test data 
in case those problems eat it, which unfortunately they have a 
significantly real chance of doing, with raid56 at this point.

So you need to get off of it ASAP, and hope any data that wasn't already 
throw-away-value, doesn't end up being thrown away anyway, in the process.

Unfortunately, as I said in the earlier post, I'm just a user, tho a list 
regular, myself, not a dev.  And I've been staying well away from raid56 
/because/ of these problems (as well as because it didn't fit my use-case 
in the first place), so other than noting the severity of the issues, 
I've not really been paying attention to the various threads with people 
trying to fix the problems and save at least some of their raid56 stored 
data.

So if you want to try to save the data, you'll need help from a dev or 
higher level expert, or failing that, at least to examine the last couple 
2-3 months worth of list threads and find the raid56 ones with methods to 
try to save what can be saved, and possibly to patch at least some of the 
problems in ordered to not make the problem worse while you're doing so.

But it's going to require some reasonable technical know-how to try to do 
that, as well as the time and hassle, so honestly, unless that data's 
/really/ worth it, it may be better to simply cut and run, doing a fresh 
mkfs and being done with btrfs raid56 for now, without spending more time 
on it, only to find you can't save much anyway.  Tho if it's worth it to 
you, you may be able to save much of it, but you could spend a month's 
man-hours doing it too and possibly still come up empty.  Plus be 
careful, because stuff like scrub that would normally help, can make the 
problem much much worse in the case of raid56 ATM.  Yes, the problems 
with it ATM *are* that bad.  Unfortunately.  There's actually talk of 
scrapping the code (almost?) entirely and starting over again, as there's 
a real question as to whether it can even be properly fixed, tho I'm not 
sure it will come to that.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: mounting failed any file on my filesystem
  2016-12-31  5:05     ` Duncan
@ 2017-01-01 17:24       ` Jan Koester
  0 siblings, 0 replies; 5+ messages in thread
From: Jan Koester @ 2017-01-01 17:24 UTC (permalink / raw)
  To: Duncan; +Cc: linux-btrfs

On Samstag, 31. Dezember 2016 05:05:03 CET Duncan wrote:
> Jan Koester posted on Fri, 30 Dec 2016 13:17:37 +0100 as excerpted:
> > sudo btrfs filesystem df /mnt
> > Data, RAID6: total=1.22TiB, used=0.00B
> > System, RAID6: total=96.00MiB, used=0.00B
> > Metadata, RAID6: total=8.25GiB, used=80.00KiB
> > GlobalReserve, single: total=512.00MiB, used=8.00KiB
> 
> Expanding on what I already mentioned in passing (hoping it wasn't the
> case), raid56 mode (so including your raid6) remains quite unstable, with
> known problems that make it unsuitable for the sort of purposes people
> normally run parity-raid for.  So it's actively negatively recommended
> unless you're running it for the specific purpose of trying to help the
> devs work out the problems with it, using only throw-away-value test data
> in case those problems eat it, which unfortunately they have a
> significantly real chance of doing, with raid56 at this point.
> 
> So you need to get off of it ASAP, and hope any data that wasn't already
> throw-away-value, doesn't end up being thrown away anyway, in the process.
> 
> Unfortunately, as I said in the earlier post, I'm just a user, tho a list
> regular, myself, not a dev.  And I've been staying well away from raid56
> /because/ of these problems (as well as because it didn't fit my use-case
> in the first place), so other than noting the severity of the issues,
> I've not really been paying attention to the various threads with people
> trying to fix the problems and save at least some of their raid56 stored
> data.
> 
> So if you want to try to save the data, you'll need help from a dev or
> higher level expert, or failing that, at least to examine the last couple
> 2-3 months worth of list threads and find the raid56 ones with methods to
> try to save what can be saved, and possibly to patch at least some of the
> problems in ordered to not make the problem worse while you're doing so.
> 
> But it's going to require some reasonable technical know-how to try to do
> that, as well as the time and hassle, so honestly, unless that data's
> /really/ worth it, it may be better to simply cut and run, doing a fresh
> mkfs and being done with btrfs raid56 for now, without spending more time
> on it, only to find you can't save much anyway.  Tho if it's worth it to
> you, you may be able to save much of it, but you could spend a month's
> man-hours doing it too and possibly still come up empty.  Plus be
> careful, because stuff like scrub that would normally help, can make the
> problem much much worse in the case of raid56 ATM.  Yes, the problems
> with it ATM *are* that bad.  Unfortunately.  There's actually talk of
> scrapping the code (almost?) entirely and starting over again, as there's
> a real question as to whether it can even be properly fixed, tho I'm not
> sure it will come to that.

I have backup of this data i wan't to help the Dev's too fix this bug because i 
have enough hard drives.I can also give remote access to show what happend 
with the filesystem or other thins that could he to fix this bug. I see at the 
moment much things happened on the raid56 code.



^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-01-01 17:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-29 19:05 mounting failed any file on my filesystem Jan Koester
2016-12-29 22:31 ` Duncan
2016-12-30 12:17   ` Jan Koester
2016-12-31  5:05     ` Duncan
2017-01-01 17:24       ` Jan Koester

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.