Hi David, On 10/28/2016 09:42 AM, David Sterba wrote: > On Thu, Oct 27, 2016 at 01:05:08PM -0500, Goldwyn Rodrigues wrote: >> While deleting pending extents, we insert extents to the >> extent_tree. However, because of corruption, this might already be >> freed. We trickle the EEXISTS error and let the caller decide what >> needs to be done with it. In this case, ignore, so the repair may >> proceed. >> >> The primary motivation of this is to resolve this BUG_ON: >> extent-tree.c:2731: alloc_reserved_tree_block: Assertion `ret` >> failed, value 0 >> >> #2 assert_trace (val=0, line=2728, func=0x489510 <__func__.11558> >> "alloc_reserved_tree_block", filename=0x489065 "extent-tree.c", >> assertion=0x48cfb5 "ret") at kerncompat.h:102 #3 >> alloc_reserved_tree_block (trans=trans@entry=0x7e7240, >> root=root@entry=0x6a88a0, root_objectid=2, generation=175654, >> flags=0, key=key@entry=0x2bc5c70, level=0, >> ins=ins@entry=0x7fffffffcf30) at extent-tree.c:2728 #4 >> finish_current_insert (trans=trans@entry=0x7e7240, >> extent_root=extent_root@entry=0x6a88a0) at extent-tree.c:2108 #5 >> __free_extent (trans=trans@entry=0x7e7240, >> root=root@entry=0x6a88a0, bytenr=57127387136, num_bytes=<optimized >> out>, parent=parent@entry=0, root_objectid=<optimized out>, >> owner_objectid=0, owner_offset=owner_offset@entry=0, >> refs_to_drop=refs_to_drop@entry=1) at extent-tree.c:2410 #6 >> del_pending_extents (trans=trans@entry=0x7e7240, >> extent_root=0x6a88a0) at extent-tree.c:2448 > > Do you have a reproducer for that?
>> Signed-off-by: Goldwyn Rodrigues <rgold...@suse.com> > > Applied, thanks. > While working on a reproducer (and further testing), I found this leaves the tree in a worse condition than before. Please leave this out for now. -- Goldwyn -- 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