On Wed, Jul 11, 2018 at 07:20:32PM +0200, Christoph Hellwig wrote: > On Wed, Jul 11, 2018 at 10:15:51AM -0700, Darrick J. Wong wrote: > > Hmm, this troubles me slightly -- a short time ago you removed the "trim > > this data fork mapping to the first overlap with a cow fork mapping" > > (i.e. xfs_reflink_trim_irec_to_next_cow) behavior on the grounds that > > _writepage_map calls _map_blocks for every block in the page and so it > > was unnecessary. But this seems to put that back. Why is that? > > Because back then map_blocks did a lookup in the COW fork everytime > (unless we are already on a COW mapping), and this patch wants to > only look it up when the COW fork actually changed, so the trim is > required now. Ah, ok. Mind if I change the comment to: /* * Truncate to the next COW extent if there is one. This is the only * opportunity to do this because we can skip COW fork lookups for the * subsequent blocks in the mapping; however, the requirement to treat * the COW range separately remains. */ I also wonder why we don't need to do the same for holes, but I think the answer is that any dirty page with a cow fork mapping must also have a data fork mapping (even if it's merely a delalloc reservation) and so a hole will never overlap with a cow fork mapping. --D > -- > 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 -- 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
