On Fri, Oct 06, 2017 at 09:38:05AM +0800, Su Yue wrote: > > > On 10/06/2017 01:46 AM, David Sterba wrote: > > On Wed, Sep 27, 2017 at 02:34:36PM +0800, Su Yue wrote: > >> In original check mode(without option "--repair"), check_extent_refs() > >> always returns 0. > >> > >> Add a variable @error to record status while checking extents. > >> At the end of check_extent_refs(), let it return -EIO if @error is > >> nonzero. > >> > >> Example: > >> $ btrfs check bad-extent-inline-ref-type.raw > >> Checking filesystem on bad-extent-inline-ref-type.raw > >> UUID: 1942d6fe-617b-4499-9982-cc8ffae5447f > >> checking extents > >> corrupt extent record: key 29360128 169 16384 > >> ref mismatch on [29360128 16384] extent item 0, found 1 > >> Backref 29360128 parent 5 root 5 not found in extent tree > >> backpointer mismatch on [29360128 16384] > >> bad extent [29360128, 29376512), type mismatch with chunk > >> checking free space cache > >> checking fs roots > >> checking csums > >> checking root refs > >> found 114688 bytes used, no error found > >> total csum bytes: 0 > >> total tree bytes: 114688 > >> total fs tree bytes: 32768 > >> total extent tree bytes: 16384 > >> btree space waste bytes: 109471 > >> file data blocks allocated: 0 > >> referenced 0 > >> > >> Signed-off-by: Su Yue <suy.f...@cn.fujitsu.com> > > > > With this patch applied, the test fsck/006 fails, is that intentional? > > > Yes, it's expected. This patch just let btrfs-progs return a correct > value.
Ok thanks. I'll add a note about that to the changelog, this kind of information is important when we knowingly break bisectability. -- 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
