Thread (47 messages) 47 messages, 4 authors, 2017-09-21

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

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..
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help