On 2014-09-19 13:54, Chris Murphy wrote:
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn wrote:
[ 30.920536] BTRFS: bad tree block start 0 130402254848
[ 30.924018] BTRFS: bad tree block start 0 130402254848
[ 30.926234] BTRFS: failed to read log tree
[ 30.953055] BTRFS: open_ctree fa
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn wrote:
[ 30.920536] BTRFS: bad tree block start 0 130402254848
[ 30.924018] BTRFS: bad tree block start 0 130402254848
[ 30.926234] BTRFS: failed to read log tree
[ 30.953055] BTRFS: open_ctree failed
I'm still confused. Btrfs knows this
On 2014-09-19 13:07, Chris Murphy wrote:
Possibly btrfs-select-super can do some of the things I was doing the hard way. It's
possible to select a super to overwrite other supers, even if they're "good"
ones. Whereas btrfs rescue super-recover won't do that, and neither will btrfsck, hence
why
Possibly btrfs-select-super can do some of the things I was doing the hard way.
It's possible to select a super to overwrite other supers, even if they're
"good" ones. Whereas btrfs rescue super-recover won't do that, and neither will
btrfsck, hence why I corrupted the one I didn't want first. T
Austin S Hemmelgarn posted on Thu, 18 Sep 2014 13:12:03 -0400 as
excerpted:
> Secondarily, this almost makes me want to set the ssd option on all
> BTRFS filesystems, just to get the rotating superblock updates, because
> if it weren't for that behavior, I probably wouldn't have been able to
> rec
On Sep 18, 2014, at 11:12 AM, Austin S Hemmelgarn wrote:
> On 09/17/2014 02:57 PM, Chris Murphy wrote:
>>
>> On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn
>> wrote:
>>>
>>> Thanks for all the help.
>>
>> Well, it's not much help. It seems possible to "corrupt" a primary
>> superblock th
On 09/17/2014 04:22 PM, Duncan wrote:
> Austin S Hemmelgarn posted on Wed, 17 Sep 2014 07:23:46 -0400 as
> excerpted:
>
>> I've also discovered, when trying to use btrfs restore to copy out the
>> data to a different system, that 3.14.1 restore apparently chokes on
>> filesystem that have lzo comp
On 09/17/2014 02:57 PM, Chris Murphy wrote:
>
> On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn wrote:
>>
>> Thanks for all the help.
>
> Well, it's not much help. It seems possible to "corrupt" a primary superblock
> that points to a corrupt tree root, and use btrfs rescure super-recover to
Austin S Hemmelgarn posted on Wed, 17 Sep 2014 07:23:46 -0400 as
excerpted:
> I've also discovered, when trying to use btrfs restore to copy out the
> data to a different system, that 3.14.1 restore apparently chokes on
> filesystem that have lzo compression turned on. It's reporting errors
> try
Chris Murphy posted on Wed, 17 Sep 2014 12:57:59 -0600 as excerpted:
> But I think you're onto something, that a good superblock can point to a
> corrupt tree root, and then not have a straight forward way to mount the
> good tree root. If I understand this correctly.
This is what I ran into myse
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn wrote:
>
> Thanks for all the help.
Well, it's not much help. It seems possible to "corrupt" a primary superblock
that points to a corrupt tree root, and use btrfs rescure super-recover to
replace it, and then mount should work. One thing I did
On 2014-09-16 16:57, Chris Murphy wrote:
>
> On Sep 16, 2014, at 8:40 AM, Austin S Hemmelgarn wrote:
>
>> Based on the kernel messages, the primary issue is log corruption, and
>> in theory btrfs-zero-log should fix it.
>
> Can you provide a complete dmesg somewhere for this initial failure, ju
On Sep 16, 2014, at 8:40 AM, Austin S Hemmelgarn wrote:
> Based on the kernel messages, the primary issue is log corruption, and
> in theory btrfs-zero-log should fix it.
Can you provide a complete dmesg somewhere for this initial failure, just for
reference? I'm curious what this indication l
13 matches
Mail list logo
