| Message ID | 20190424124829.14277-1-wqu@suse.com |
|---|---|
| State | New |
| Headers | show |
| Series |
|
| Related | show |
On 24.04.19 г. 15:48 ч., Qu Wenruo wrote: > Let's dump the leaf content before triggering BUG_ON() so that we can > have some clue on what's going wrong. > The output of tree locks should help us to debug such problem. > The reason is some sort of in-memory corruption/confusion of the extent maps, causing overlapping extents. However so far it hasn't been possible to reproduce that on-demand to actually debug it. Filipe suspected it has to do with extent mapping merging logic. This only occurs when working with the log tree which takes its data from the in-memory extent mapping tree.
On 2019/4/24 下午8:52, Nikolay Borisov wrote: > > > On 24.04.19 г. 15:48 ч., Qu Wenruo wrote: >> Let's dump the leaf content before triggering BUG_ON() so that we can >> have some clue on what's going wrong. >> The output of tree locks should help us to debug such problem. >> > > The reason is some sort of in-memory corruption/confusion of the extent > maps, causing overlapping extents. However so far it hasn't been > possible to reproduce that on-demand to actually debug it. Filipe > suspected it has to do with extent mapping merging logic. This only > occurs when working with the log tree which takes its data from the > in-memory extent mapping tree. Anyway, this won't hurt. right? If it gives us some clue, that's the best case. If not, it won't make the current situation worse, right? Thanks, Qu
On Wed, Apr 24, 2019 at 1:57 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote: > > > > On 2019/4/24 下午8:52, Nikolay Borisov wrote: > > > > > > On 24.04.19 г. 15:48 ч., Qu Wenruo wrote: > >> Let's dump the leaf content before triggering BUG_ON() so that we can > >> have some clue on what's going wrong. > >> The output of tree locks should help us to debug such problem. > >> > > > > The reason is some sort of in-memory corruption/confusion of the extent > > maps, causing overlapping extents. However so far it hasn't been > > possible to reproduce that on-demand to actually debug it. Filipe > > suspected it has to do with extent mapping merging logic. This only > > occurs when working with the log tree which takes its data from the > > in-memory extent mapping tree. > > Anyway, this won't hurt. right? > > If it gives us some clue, that's the best case. > If not, it won't make the current situation worse, right? Right, but dumping the leaf alone, may not tell you much (I've been there). Printing the new key and slot, together with the leaf dump, helps much more. Thanks. > > Thanks, > Qu
On 2019/4/24 下午9:53, Filipe Manana wrote: > On Wed, Apr 24, 2019 at 1:57 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote: >> >> >> >> On 2019/4/24 下午8:52, Nikolay Borisov wrote: >>> >>> >>> On 24.04.19 г. 15:48 ч., Qu Wenruo wrote: >>>> Let's dump the leaf content before triggering BUG_ON() so that we can >>>> have some clue on what's going wrong. >>>> The output of tree locks should help us to debug such problem. >>>> >>> >>> The reason is some sort of in-memory corruption/confusion of the extent >>> maps, causing overlapping extents. However so far it hasn't been >>> possible to reproduce that on-demand to actually debug it. Filipe >>> suspected it has to do with extent mapping merging logic. This only >>> occurs when working with the log tree which takes its data from the >>> in-memory extent mapping tree. >> >> Anyway, this won't hurt. right? >> >> If it gives us some clue, that's the best case. >> If not, it won't make the current situation worse, right? > > Right, but dumping the leaf alone, may not tell you much (I've been there). > Printing the new key and slot, together with the leaf dump, helps much more. Right, I'd add them. Thanks, Qu > > Thanks. > >> >> Thanks, >> Qu > > >
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index f52eb952597b..c769a7b50ba4 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -3185,10 +3185,12 @@ void btrfs_set_item_key_safe(struct btrfs_fs_info *fs_info, slot = path->slots[0]; if (slot > 0) { btrfs_item_key(eb, &disk_key, slot - 1); + btrfs_print_leaf(eb); BUG_ON(comp_keys(&disk_key, new_key) >= 0); } if (slot < btrfs_header_nritems(eb) - 1) { btrfs_item_key(eb, &disk_key, slot + 1); + btrfs_print_leaf(eb); BUG_ON(comp_keys(&disk_key, new_key) <= 0); }
We have a user reporting BUG_ON() triggered in btrfs_set_item_key_safe(). Let's dump the leaf content before triggering BUG_ON() so that we can have some clue on what's going wrong. The output of tree locks should help us to debug such problem. Signed-off-by: Qu Wenruo <wqu@suse.com> --- fs/btrfs/ctree.c | 2 ++ 1 file changed, 2 insertions(+)