linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4
@ 2015-07-09  3:15 Chris Murphy
  2015-07-23  3:41 ` Zhao Lei
  0 siblings, 1 reply; 4+ messages in thread
From: Chris Murphy @ 2015-07-09  3:15 UTC (permalink / raw)
  To: Btrfs BTRFS

OK yet another btrfs-convert bug. This one is easier to reproduce than
the others, does not damage the file system (still mounts OK) but the
oops is a hard panic. ssh and even the virt-manager console dies
instantly, but virsh console captured a lot of call traces and are
attached to the bug report.

Happens with 4.1 and 4.2rc1 kernels. The convert was done with btrfs-progs 4.1.

The reproduce steps are easy:

1. ext4 with a bunch of files (Fedora 22 installation) plus a ~1.5GB ISO
2. btrfs-convert using defaults goes OK no error, btrfs check has no complaints
3. mount
4. btrfs scrub
hard panic

https://bugzilla.kernel.org/show_bug.cgi?id=101231


-- 
Chris Murphy

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4
  2015-07-09  3:15 [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4 Chris Murphy
@ 2015-07-23  3:41 ` Zhao Lei
  2015-08-26  9:44   ` Yurii Kolesnykov
  0 siblings, 1 reply; 4+ messages in thread
From: Zhao Lei @ 2015-07-23  3:41 UTC (permalink / raw)
  To: 'Chris Murphy', 'Btrfs BTRFS'; +Cc: 'Qu Wenruo'

Hi, Chris Murphy

Thanks for report this bug.

> -----Original Message-----
> From: linux-btrfs-owner@vger.kernel.org
> [mailto:linux-btrfs-owner@vger.kernel.org] On Behalf Of Chris Murphy
> Sent: Thursday, July 09, 2015 11:16 AM
> To: Btrfs BTRFS
> Subject: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly
> converted ext4
> 
> OK yet another btrfs-convert bug. This one is easier to reproduce than the
> others, does not damage the file system (still mounts OK) but the oops is a hard
> panic. ssh and even the virt-manager console dies instantly, but virsh console
> captured a lot of call traces and are attached to the bug report.
> 
> Happens with 4.1 and 4.2rc1 kernels. The convert was done with btrfs-progs
> 4.1.
> 
> The reproduce steps are easy:
> 
> 1. ext4 with a bunch of files (Fedora 22 installation) plus a ~1.5GB ISO 2.
> btrfs-convert using defaults goes OK no error, btrfs check has no complaints 3.
> mount 4. btrfs scrub hard panic
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=101231
> 

I reproduced above bug too, with following command:
  mkfs.ext4 /dev/vdh
  btrfs-convert /dev/vdh
  mount /dev/vdh /mnt/tmp1
  btrfs scrub start -B /dev/vdh
  (panic)

The reason is:
1: In some case, metadata(leaf) created by btrfs-convert was split into 2 strips.
2: Then scrub bypassed part of leaf data, and left data caused panic in
  scrub_checksum_tree_block().

For above 1:
we can get following information after some simple operation.
a. mkfs.ext4 /dev/vdh
  btrfs-convert /dev/vdh
b. btrfs-debug-tree /dev/vdh
  we can see following item in extent tree:
  item 25 key (27054080 METADATA_ITEM 0) itemoff 15083 itemsize 33
  Its logical address is [27054080, 27070464)
  and acrossed 2 strips:
  [27000832, 27066368)
  [27066368, 27131904)
Qu Wenruo <quwenruo@cn.fujitsu.com> is fixing above problem.

For above 2:
scrub is trying to do a "bypass" in this case, but the result is "panic".
I'll fix it.

Thanks
Zhaolei

> 
> --
> Chris Murphy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4
  2015-07-23  3:41 ` Zhao Lei
@ 2015-08-26  9:44   ` Yurii Kolesnykov
  2015-08-26 10:28     ` Zhao Lei
  0 siblings, 1 reply; 4+ messages in thread
From: Yurii Kolesnykov @ 2015-08-26  9:44 UTC (permalink / raw)
  To: Zhao Lei, 'Chris Murphy', 'Btrfs BTRFS'
  Cc: 'Qu Wenruo'

Hi, Zhao Lei

> 
> I reproduced above bug too, with following command:
>   mkfs.ext4 /dev/vdh
>   btrfs-convert /dev/vdh
>   mount /dev/vdh /mnt/tmp1
>   btrfs scrub start -B /dev/vdh
>   (panic)
> 
> The reason is:
> 1: In some case, metadata(leaf) created by btrfs-convert was split into 2 strips.
> 2: Then scrub bypassed part of leaf data, and left data caused panic in
>   scrub_checksum_tree_block().
> 
> For above 1:
> we can get following information after some simple operation.
> a. mkfs.ext4 /dev/vdh
>   btrfs-convert /dev/vdh
> b. btrfs-debug-tree /dev/vdh
>   we can see following item in extent tree:
>   item 25 key (27054080 METADATA_ITEM 0) itemoff 15083 itemsize 33
>   Its logical address is [27054080, 27070464)
>   and acrossed 2 strips:
>   [27000832, 27066368)
>   [27066368, 27131904)
> Qu Wenruo <quwenruo@cn.fujitsu.com> is fixing above problem.
> 
> For above 2:
> scrub is trying to do a "bypass" in this case, but the result is "panic".
> I'll fix it.
> 
> Thanks
> Zhaolei

Could you please share an update on this bug status?
Also, please use bugzilla.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4
  2015-08-26  9:44   ` Yurii Kolesnykov
@ 2015-08-26 10:28     ` Zhao Lei
  0 siblings, 0 replies; 4+ messages in thread
From: Zhao Lei @ 2015-08-26 10:28 UTC (permalink / raw)
  To: 'Yurii Kolesnykov', 'Chris Murphy',
	'Btrfs BTRFS'
  Cc: 'Qu Wenruo'

Hi, Yurii Kolesnykov

> -----Original Message-----
> From: Yurii Kolesnykov [mailto:yurikoles@gmail.com]
> Sent: Wednesday, August 26, 2015 5:44 PM
> To: Zhao Lei <zhaolei@cn.fujitsu.com>; 'Chris Murphy'
> <lists@colorremedies.com>; 'Btrfs BTRFS' <linux-btrfs@vger.kernel.org>
> Cc: 'Qu Wenruo' <quwenruo@cn.fujitsu.com>
> Subject: Re: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing
> freshly converted ext4
> 
> Hi, Zhao Lei
> 
> >
> > I reproduced above bug too, with following command:
> >   mkfs.ext4 /dev/vdh
> >   btrfs-convert /dev/vdh
> >   mount /dev/vdh /mnt/tmp1
> >   btrfs scrub start -B /dev/vdh
> >   (panic)
> >
> > The reason is:
> > 1: In some case, metadata(leaf) created by btrfs-convert was split into 2
> strips.
> > 2: Then scrub bypassed part of leaf data, and left data caused panic in
> >   scrub_checksum_tree_block().
> >
> > For above 1:
> > we can get following information after some simple operation.
> > a. mkfs.ext4 /dev/vdh
> >   btrfs-convert /dev/vdh
> > b. btrfs-debug-tree /dev/vdh
> >   we can see following item in extent tree:
> >   item 25 key (27054080 METADATA_ITEM 0) itemoff 15083 itemsize 33
> >   Its logical address is [27054080, 27070464)
> >   and acrossed 2 strips:
> >   [27000832, 27066368)
> >   [27066368, 27131904)
> > Qu Wenruo <quwenruo@cn.fujitsu.com> is fixing above problem.
> >	
> > For above 2:
> > scrub is trying to do a "bypass" in this case, but the result is "panic".
> > I'll fix it.
> >
> > Thanks
> > Zhaolei
> 
> Could you please share an update on this bug status?

Above 1 is fixed in patch titled:
[PATCH] btrfs: Fix scrub panic when leaf accross stripes
in btrfs maillist.

This patch is in integration-4.3 branch, and will be merged
into linux 4.3.

For above 2, it is fixed by Qu Wenruo <quwenruo@cn.fujitsu.com>,
patch set is btrfs maillist named:
 [PATCH 0/4] Metadata crossing stripe boundary fixes
 ...

These patch are already in new version of btrfs-progs now.

> Also, please use bugzilla.

I failed to close the bug in Bugzilla, maybe no permission, or
oher problem for newbee as I.

Maybe 'Chris Murphy' <lists@colorremedies.com> can close it.

Thanks
Zhaolei



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-08-26 10:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-09  3:15 [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4 Chris Murphy
2015-07-23  3:41 ` Zhao Lei
2015-08-26  9:44   ` Yurii Kolesnykov
2015-08-26 10:28     ` Zhao Lei

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).