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 quwen...@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. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4
Hi, Yurii Kolesnykov -Original Message- From: Yurii Kolesnykov [mailto:yuriko...@gmail.com] Sent: Wednesday, August 26, 2015 5:44 PM To: Zhao Lei zhao...@cn.fujitsu.com; 'Chris Murphy' li...@colorremedies.com; 'Btrfs BTRFS' linux-btrfs@vger.kernel.org Cc: 'Qu Wenruo' quwen...@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 quwen...@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 quwen...@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' li...@colorremedies.com can close it. Thanks Zhaolei -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [BUG] kernel BUG at fs/btrfs/scrub.c:1956!, when scrubbing freshly converted ext4
Hi, Chris Murphy Thanks for report this bug. -Original Message- From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-ow...@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 quwen...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
