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.
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
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn ahferro...@gmail.com 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
On 2014-09-19 13:54, Chris Murphy wrote:
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn ahferro...@gmail.com 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]
On 09/17/2014 02:57 PM, Chris Murphy wrote:
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn ahferro...@gmail.com 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
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 compression
On Sep 18, 2014, at 11:12 AM, Austin S Hemmelgarn ahferro...@gmail.com wrote:
On 09/17/2014 02:57 PM, Chris Murphy wrote:
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn ahferro...@gmail.com
wrote:
Thanks for all the help.
Well, it's not much help. It seems possible to corrupt a
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
On 2014-09-16 16:57, Chris Murphy wrote:
On Sep 16, 2014, at 8:40 AM, Austin S Hemmelgarn ahferro...@gmail.com 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
On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn ahferro...@gmail.com 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
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 myself
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
trying
So, I just recently had to hard reset a system running root on BTRFS,
and when it tried to come back up, it chocked on the root filesystem.
Based on the kernel messages, the primary issue is log corruption, and
in theory btrfs-zero-log should fix it. The actual issue however, is
that the primary
On Sep 16, 2014, at 8:40 AM, Austin S Hemmelgarn ahferro...@gmail.com 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
14 matches
Mail list logo
