From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:60464 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S945521AbcJaSnZ (ORCPT ); Mon, 31 Oct 2016 14:43:25 -0400 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 50A64ABC8 for ; Mon, 31 Oct 2016 18:43:23 +0000 (UTC) Subject: Re: [PATCH] btrfs-progs: repair: Trickle down EEXISTS while freeing To: dsterba@suse.cz, linux-btrfs@vger.kernel.org References: <20161027180508.8721-1-rgoldwyn@suse.de> <20161028144202.GH12522@twin.jikos.cz> From: Goldwyn Rodrigues Message-ID: <211e0109-1ce7-44fd-1e73-a1f1a96c44e2@suse.de> Date: Mon, 31 Oct 2016 13:43:20 -0500 MIME-Version: 1.0 In-Reply-To: <20161028144202.GH12522@twin.jikos.cz> Content-Type: text/plain; charset=windows-1252 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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=> out>, parent=parent@entry=0, root_objectid=, >> 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 > > 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