On Tue, Jan 31, 2017 at 11:11:20AM -0800, Darrick J. Wong wrote: > On Tue, Jan 31, 2017 at 05:41:35AM -0800, Christoph Hellwig wrote: > > Hi Darrick, > > > > from a quick look the code looks reasonable, but I'm worried about > > yet another set of transactions that modify all extents again. > > > > Do you have any measurements of the overhead? I'll see if I > > can prototype my always COW idea to see how the approaches compare. > > The overhead should be pretty low -- since the cow fork never goes to > disk, the only thing we end up logging is the inode core (because the > conversion function logs it unconditionally), and I'm not even sure > that's necessary since we're performing a pure conversion of blocks that > are already allocated. > > In any case I didn't see any noticeable impact on performance other > than the extra CPU overhead. Reading a little closer, we don't actually change anything in the on-disk inode, so we can get rid of transaction altogether. --D > > --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 -- 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
