On Tue, Jan 24, 2017 at 10:02:22AM -0500, Brian Foster wrote: > Ok, well then I'm probably not going to be able to follow the details > well enough to try and provide constructive feedback without seeing the > code. Looking back, my comments were generally about the tradeoff of > bypassing the extent size hint mechanism that has been built into > reflink to avoid cow fragmention. Ok - really very little change here - only the call to the extsize alignment in xfs_bmap_btalloc reinstated and the according reservation changes in the caller. Note that with the previously posted series there is no change in handling the cowextsize hint for real on-disk allocations. While the current code rounds down based on the cowextsize for creating the delayed extent we will never convert the alignment before the write start to a real extent - it will just get cleaned up later at inode eviction time or using the timer. > Without seeing the code, perhaps we need to pull up the cow extent size > hint mechanism from the bmapi layer to something similar to how > xfs_iomap_direct_write() handles the traditional extent size hints..? > That may allow us to more intelligently consider the current state > across the data and cow forks in such cases (to not preallocate over > existing blocks, for example, without having to kill off the extent size > hint entirely). We could. On the other hand I'd love to get the current series in first as the only thing it change in behavior is not allocating additional delayed extent space that never gets used, and not writing data twice if it's sub-blocksize, all of which seem like a clear improvement. And it's also the base for my pending DAX reflink support. -- 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
