On Wed, Aug 5, 2015 at 8:31 AM, Sonic 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.
Someho
On Tue, Aug 4, 2015 at 4:23 PM, Sonic 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 reit
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 i
=8330001001141004672
Couldn't read chunk root
Couldn't open file system
On Mon, Aug 3, 2015 at 10:20 PM, Sonic wrote:
> On Mon, Aug 3, 2015 at 12:32 PM, Sonic wrote:
>> btrfs rescue chunk-recover
>
> Ran this:
> btrfs rescue chunk-recover -v /dev/sde |tee brcr.txt
>
On Mon, Aug 3, 2015 at 12:32 PM, Sonic 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: 3
Mon, Aug 3, 2015 at 12:22 PM, Sonic 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
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 8B1D96
] BTRFS: failed to read chunk root on sde
[88228.769877] BTRFS: open_ctree failed
On Mon, Aug 3, 2015 at 12:03 PM, Sonic wrote:
> On Mon, Aug 3, 2015 at 11:28 AM, Hugo Mills wrote:
>>Very unlikely and definitely not, respectively. There's nothing at
>> all here to indica
On Mon, Aug 3, 2015 at 11:28 AM, Hugo Mills 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
On Mon, Aug 3, 2015 at 10:43 AM, Sonic wrote:
> Is "btrfs rescue super-recover" safe to run? IOW, will it ask before
> doing anything possibly destructive (assuming I don't give it a -y)?
Seemed a bit safe so I went for it and:
sartre ~ # btrfs rescue super-recover /dev/sdc
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,
On Mon, Aug 3, 2015 at 1:42 AM, Chris Murphy wrote:
> I can't tell what the data and metadata profile are? That it won't
> mount degraded makes me think the metadata is not explicitly raid1;
> and it either raid0 or accidentally single or dup which can happen at
> mkfs time on single device
It's
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 b
13 matches
Mail list logo
