On Fri, Jul 24, 2015 at 09:24:46AM -0700, Marc MERLIN wrote:
Screenshot: http://marc.merlins.org/tmp/btrfs_crash.jpg
So it's 32bit system, 3.19.8, crashing during snapshot deletion and
backref walking. EIP is in do_walk_down+0x142. I've tried to match it to
the sources on a local
Hello,
Looking at the btrfs fi show output, you've probably run out of
space during the conversion, probably due to an uneven distribution of
the original single chunks.
I think I would suggest balancing the single chunks, and trying the
conversion (of the unconverted parts) again:
#
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
On Sun, Aug 02, 2015 at 12:31:13PM -0600, Chris Murphy wrote:
On Sat, Aug 1, 2015 at 9:46 PM, Duncan 1i5t5.dun...@cox.net wrote:
If it was setup with something earlier (not sure about 4.1.0, was it
affected?
No.
but 4.0.x and earlier should be fine for setup), however, once
on a
On Sat, Aug 1, 2015 at 9:46 PM, Duncan 1i5t5.dun...@cox.net wrote:
If it was setup with something earlier (not sure about 4.1.0, was it
affected?
No.
but 4.0.x and earlier should be fine for setup), however, once
on a new kernel the usual ENOSPC workarounds can be given a try. That
would
Sonic posted on Sun, 02 Aug 2015 13:13:41 -0400 as excerpted:
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
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, and just doing btrfs dev add to add
another device.
I think
Thanks for the log.
I'll investigate it to see whether we can resolve the infinite loop problem.
Thanks,
Qu
Robert Munteanu wrote on 2015/07/31 16:38 +0300:
On Fri, Jul 31, 2015 at 5:08 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Any full output about it?
Please see the attached log. I
Yes, you're right, that's a dead loop.
But for better debugging, would you please upload the following info?
1) output of command btrfs-debug-tree -t 5 DEV.
The only important things are info about that inode.
Whose objectid(first item in a key) is 14214570 and type is one of the
following:
