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
