Re: [PATCH 12/19] xfs: refactor xfs_bmap_add_extent_delay_real
From: Christoph Hellwig <hch@lst.de>
Date: 2017-09-21 13:27:36
From: Christoph Hellwig <hch@lst.de>
Date: 2017-09-21 13:27:36
On Tue, Sep 19, 2017 at 12:35:25PM -0400, Brian Foster wrote:
quoted
@@ -2064,12 +2082,12 @@ xfs_bmap_add_extent_delay_real( if (error) goto done; } - temp = xfs_bmap_worst_indlen(bma->ip, temp); - temp2 = xfs_bmap_worst_indlen(bma->ip, temp2); - diff = (int)(temp + temp2 - - (startblockval(PREV.br_startblock) - - (bma->cur ? - bma->cur->bc_private.b.allocated : 0))); + + da_new = startblockval(PREV.br_blockcount) + + startblockval(RIGHT.br_blockcount);s/br_blockcount/br_startblock/ :)
Yes. And I've officially lost all faith in xfstests ever even testing this case in xfs_bmap_add_extent_delay_real at all. I think it should be really easily testable by creating a large delalloc reservation and then fsyncing out the middle of it. Except of course we don't have a range fsync, and even then the writeback code might cluster it. I might have to come up with a special kernel module to even reproduce this reliably..