On Fri, Mar 16, 2018 at 11:19:55AM +1100, Dave Chinner wrote: > On Thu, Mar 15, 2018 at 11:32:07AM +0100, Lukas Czerner wrote: > > > > And where the "cdcd" data is comming from ? Not from the > > > > "pwrite -S 1 0 64k" > > > > that's producing "0101". > > Ah, too much context switching. Makes me look like the village > idiot... that's how I was looking the past 4 emails ;) Anyway good that we finally understand each other. I think it'd be worth fixing the generic/042 to check for the actuall stale data not just expecting the file to be empty as it still can do some good. > > Ok, I just spent some time looking at this in detail (event traces, > etc) and it is indeed as the test describes - an whole delalloc > extent allocation on partial overwrite. THe partial overwrite is > triggered by the fpunch/fzero code, and it appears the delalloc > converison is not paying attention to the start offset of the > writeback: > > xfs_writepage: dev 7:0 ino 0x7603 pgoff 0xf000 size 0x10000 delalloc 1 > ..... > xfs_alloc_near_greater: dev 7:0 agno 0 agbno 3784 minlen 16 maxlen 16 > ..... > xfs_write_extent: dev 7:0 ino 0x7603 offset 0 block 3784 count 16 flag 0 > > IOWs, as I've said from the start (based on the test description) > this has nothing to do with the corruption issue CrashMonkey is > creating. Yeah they're probably not seeing this because of added fsync. -Lukas > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
