Re: BTRFS disaster (of my own making). Is this recoverable?
On Tue, Aug 4, 2015 at 4:23 PM, Sonic sonicsm...@gmail.com wrote: Seems that if there was someway to edit something in those first overwritten 32MB of disc 2 to say hey, I'm really here, just a bit screwed up maybe some of the recovery tools could actually work. Just want to reiterate this thought. The basic error in most cases with the tools at hand is that Disc 2 is missing so there's little the tools can do. Somewhere in those first 32MB should be something to properly identify the disc as part of the array. If the btrfs tools can't fix it maybe dd can. Is there anything can be gained from the beginning of disc 1 (can dd this to a file) in order to create the necessary bits needed at the beginning of disc2? Or some other way to overwrite the beginning of disc 2 (using dd again) with some identification information so that the automated btrfs tools can take it from there? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
On Wed, Aug 5, 2015 at 8:31 AM, Sonic sonicsm...@gmail.com wrote: The basic error in most cases with the tools at hand is that Disc 2 is missing so there's little the tools can do. Somewhere in those first 32MB should be something to properly identify the disc as part of the array. Somehow manually create the missing chunk root if this is the core problem?? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
On Tue, Aug 4, 2015 at 1:10 AM, Duncan 1i5t5.dun...@cox.net wrote: I don't remember you saying anything about trying btrfs restore. I did try it earlier in dry-run mode and it can't do anything: = btrfs restore -D /dev/sdc /mnt/saved/ warning, device 2 is missing bytenr mismatch, want=20971520, have=0 Couldn't read chunk root Could not open root, trying backup super warning, device 2 is missing bytenr mismatch, want=20971520, have=0 Couldn't read chunk root Could not open root, trying backup super warning, device 2 is missing bytenr mismatch, want=20971520, have=0 Couldn't read chunk root Could not open root, trying backup super = Find-roots, list-roots, none of it works. = btrfs restore --list-roots /dev/sde checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 bytenr mismatch, want=20971520, have=8330001001141004672 Couldn't read chunk root Could not open root, trying backup super warning, device 1 is missing checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 bytenr mismatch, want=20971520, have=8330001001141004672 Couldn't read chunk root Could not open root, trying backup super warning, device 1 is missing checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 bytenr mismatch, want=20971520, have=8330001001141004672 Couldn't read chunk root Could not open root, trying backup super = btrfs-find-root -a /dev/sdc warning, device 2 is missing Couldn't read chunk root btrfs-find-root -a /dev/sde Couldn't read chunk root Open ctree failed = In defense of BTRFS it's been absolutely trouble free keeping my data through many power outages, etc. and I plan to keep using it. It was my own doing that caused the problem. Seems that if there was someway to edit something in those first overwritten 32MB of disc 2 to say hey, I'm really here, just a bit screwed up maybe some of the recovery tools could actually work. Thanks to all. Chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
On Mon, Aug 3, 2015 at 1:17 AM, Duncan 1i5t5.dun...@cox.net wrote: The first thing you need to do in terms of trying to recover, is restore the superblock on the damaged device. Since btrfs keeps multiple copies (up to three, once the filesystem is large enough, as yours is) per device, that's actually relatively easy. Use... btrfs rescue super-recover Not sure how to tell if there is a superblock issue: === btrfs-show-super -f /dev/sdc superblock: bytenr=65536, device=/dev/sdc - dev_item.type 0 dev_item.total_bytes4000787030016 dev_item.bytes_used 3527267057664 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0 sys_chunk_array[2048]: item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520) chunk length 16777216 owner 2 type SYSTEM|RAID0 num_stripes 2 stripe 0 devid 2 offset 1048576 stripe 1 devid 1 offset 20971520 backup_roots[4]: backup 0: backup_tree_root: 1517037699072 gen: 9025 level: 1 backup_chunk_root: 20971520gen: 8957 level: 1 backup_extent_root: 576585728 gen: 9025 level: 2 backup_fs_root: 2056568832 gen: 1106 level: 0 backup_dev_root:52576256gen: 9021 level: 1 backup_csum_root: 1517028753408 gen: 9025 level: 3 backup_total_bytes: 8001574060032 backup_bytes_used: 7038625824768 backup_num_devices: 2 backup 1: backup_tree_root: 1517167755264 gen: 9026 level: 1 backup_chunk_root: 20971520gen: 8957 level: 1 backup_extent_root: 1517167771648 gen: 9026 level: 2 backup_fs_root: 2056568832 gen: 1106 level: 0 backup_dev_root:52576256gen: 9021 level: 1 backup_csum_root: 2503711637504 gen: 9026 level: 3 backup_total_bytes: 8001574060032 backup_bytes_used: 7038625824768 backup_num_devices: 2 backup 2: backup_tree_root: 980877312 gen: 9023 level: 1 backup_chunk_root: 20971520gen: 8957 level: 1 backup_extent_root: 1026768896 gen: 9023 level: 2 backup_fs_root: 2056568832 gen: 1106 level: 0 backup_dev_root:52576256gen: 9021 level: 1 backup_csum_root: 1790377984 gen: 9023 level: 3 backup_total_bytes: 8001574060032 backup_bytes_used: 7038617616384 backup_num_devices: 2 backup 3: backup_tree_root: 1960509440 gen: 9024 level: 1 backup_chunk_root: 20971520gen: 8957 level: 1 backup_extent_root: 1960525824 gen: 9024 level: 2 backup_fs_root: 2056568832 gen: 1106 level: 0 backup_dev_root:52576256gen: 9021 level: 1 backup_csum_root: 2106736640 gen: 9024 level: 3 backup_total_bytes: 8001574060032 backup_bytes_used: 7038617616384 backup_num_devices: 2 btrfs-show-super -f /dev/sde superblock: bytenr=65536, device=/dev/sde - csum0x9634c164 [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid09024c28-7932-4ddb-960d-becc1ea839e5 label terrafirm generation 9026 root1517167755264 sys_array_size 129 chunk_root_generation 8957 root_level 1 chunk_root 20971520 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 8001574060032 bytes_used 7038625824768 sectorsize 4096 nodesize16384 leafsize16384 stripesize 4096 root_dir6 num_devices 2 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x21 ( MIXED_BACKREF | BIG_METADATA ) csum_type 0 csum_size 4 cache_generation9026
Re: BTRFS disaster (of my own making). Is this recoverable?
On Mon, Aug 3, 2015 at 11:28 AM, Hugo Mills h...@carfax.org.uk wrote: Very unlikely and definitely not, respectively. There's nothing at all here to indicate that you've got a broken log, so dropping it would be at best pointless. The chunk tree is also most likely undamaged on both copies. Will it hurt to try a chunk-recover? I'm guessing it wont do anything unless I answer Y to some prompt. Is there anything else you would suggest? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
Also tried: mount -o recovery,ro /mnt/butter/ And dmesg gives: [88228.756622] BTRFS info (device sde): enabling auto recovery [88228.756635] BTRFS info (device sde): disk space caching is enabled [88228.757244] BTRFS (device sde): bad tree block start 8330001001141004672 20971520 [88228.757248] BTRFS: failed to read chunk root on sde [88228.769877] BTRFS: open_ctree failed On Mon, Aug 3, 2015 at 12:03 PM, Sonic sonicsm...@gmail.com wrote: On Mon, Aug 3, 2015 at 11:28 AM, Hugo Mills h...@carfax.org.uk wrote: Very unlikely and definitely not, respectively. There's nothing at all here to indicate that you've got a broken log, so dropping it would be at best pointless. The chunk tree is also most likely undamaged on both copies. Will it hurt to try a chunk-recover? I'm guessing it wont do anything unless I answer Y to some prompt. Is there anything else you would suggest? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
Output of btrfs check: btrfs check /dev/sdc warning, device 2 is missing bytenr mismatch, want=20971520, have=0 Couldn't read chunk root Couldn't open file system btrfs check /dev/sde checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 bytenr mismatch, want=20971520, have=8330001001141004672 Couldn't read chunk root Couldn't open file system In case the above helps. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
On Mon, Aug 3, 2015 at 12:32 PM, Sonic sonicsm...@gmail.com wrote: btrfs rescue chunk-recover Ran this: btrfs rescue chunk-recover -v /dev/sde |tee brcr.txt Got this (very end of output): == Unrecoverable Chunks: Total Chunks: 3292 Recoverable: 3292 Unrecoverable:0 Orphan Block Groups: Orphan Device Extents: Fail to recover the chunk tree. == If earlier output of this process might be helpful I can provide it (used tee to create a file). Didn't work - seems all chunks found were recoverable - it's apparently the missing chunks that are the problem. I'm thinking this is a lost cause. Also thinking I need to provide for some redundancy in the future :-) Any other suggestions before I give up the ghost on this? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
Out of frustration and vodka I tried: btrfs check --repair /dev/sde To instantly be met with: enabling repair mode checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 bytenr mismatch, want=20971520, have=8330001001141004672 Couldn't read chunk root Couldn't open file system On Mon, Aug 3, 2015 at 10:20 PM, Sonic sonicsm...@gmail.com wrote: On Mon, Aug 3, 2015 at 12:32 PM, Sonic sonicsm...@gmail.com wrote: btrfs rescue chunk-recover Ran this: btrfs rescue chunk-recover -v /dev/sde |tee brcr.txt Got this (very end of output): == Unrecoverable Chunks: Total Chunks: 3292 Recoverable: 3292 Unrecoverable:0 Orphan Block Groups: Orphan Device Extents: Fail to recover the chunk tree. == If earlier output of this process might be helpful I can provide it (used tee to create a file). Didn't work - seems all chunks found were recoverable - it's apparently the missing chunks that are the problem. I'm thinking this is a lost cause. Also thinking I need to provide for some redundancy in the future :-) Any other suggestions before I give up the ghost on this? Thanks, Chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS disaster (of my own making). Is this recoverable?
Are either one of these called for? btrfs check --repair or btrfs check --repair --init-csum-tree Seems like they might be a last ditch attempt. Is one preferred over the other? Is: btrfs rescue chunk-recover a much less dangerous attempt (IOW it wont hurt to try it first)? Thanks, Chris On Mon, Aug 3, 2015 at 12:22 PM, Sonic sonicsm...@gmail.com wrote: Output of btrfs check: btrfs check /dev/sdc warning, device 2 is missing bytenr mismatch, want=20971520, have=0 Couldn't read chunk root Couldn't open file system btrfs check /dev/sde checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 checksum verify failed on 20971520 found 8B1D9672 wanted 2F8A4238 bytenr mismatch, want=20971520, have=8330001001141004672 Couldn't read chunk root Couldn't open file system In case the above helps. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BTRFS disaster (of my own making). Is this recoverable?
I have had bad dreams about this particular fat finger but after a few years it has finally happened. Scenario: 2 drives in a raw btrfs array (no previous partitions and non-redundant) with various subvols as well. One was sdc the other was sde, although sde never displays with mount command and blkid is the same for both. Thinking I was writing to a flash drive I sent 32MB via dd === dd if=file of=/dev/sde === to sde (instead of what I wanted - sdf) and now the volume nor any of it's subvol's can mount (of course that seems entirely reasonable, although you can imagine how unhappy I am). With: === mount -t btrfs /mnt/butter/ === I get: === [ 3421.193103] BTRFS info (device sde): disk space caching is enabled [ 3421.193734] BTRFS (device sde): bad tree block start 8330001001141004672 20971520 [ 3421.193738] BTRFS: failed to read chunk root on sde [ 3421.203221] BTRFS: open_ctree failed === If I specify /dev/sdc instead of relying on fstab I get: === mount -t btrfs -o degraded /dev/sdc /mnt/butter/ === [ 3839.506766] BTRFS info (device sde): allowing degraded mounts [ 3839.506769] BTRFS info (device sde): disk space caching is enabled [ 3839.507154] BTRFS (device sde): bad tree block start 8330001001141004672 20971520 [ 3839.507159] BTRFS: failed to read chunk root on sde [ 3839.515023] BTRFS: open_ctree failed === Obligatory details: === uname -a Linux sartre 4.1.3-gentoo #1 SMP Sat Jul 25 22:34:14 EDT 2015 x86_64 Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz GenuineIntel GNU/Linux === btrfs --version btrfs-progs v4.1.2 === btrfs fi show Label: 'garage' uuid: 896f615e-6437-41c6-8f2a-25f73ff1af7a Total devices 1 FS bytes used 89.33GiB devid1 size 200.00GiB used 92.02GiB path /dev/sdb3 warning, device 2 is missing bytenr mismatch, want=20971520, have=0 Couldn't read chunk root Label: 'terrafirm' uuid: 09024c28-7932-4ddb-960d-becc1ea839e5 Total devices 2 FS bytes used 6.40TiB devid1 size 3.64TiB used 3.21TiB path /dev/sdc *** Some devices missing btrfs-progs v4.1.2 === btrfs fi df /mnt/butter ERROR: couldn't get space info - Inappropriate ioctl for device ERROR: get_df failed Inappropriate ioctl for device === Please advise. Thank you, Chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
