On Mon, Aug 01, 2016 at 01:02:23AM -0700, Christoph Hellwig wrote: > I looked over this again and I really don't see the use case of merging > it. Yes, the freed extent, rmap and reflink code is fairly similar, but > there is all kinds of subtile differences that we need to paper over using > methods and flags. I think we're better off not trying to share this > code and have a separate, but easily understandable implementation > for each btree. At least for the traditional traditional freed extent > case the new code also is a lot less optimal than the previous version. Rather than have to make major changes to core infrastructure now, let's work this out as a separate patchset to clean up the rmap and reflink code in the next couple of releases. It's going to be better to get working code out there now under the experimental tag than it is is to keep it as an out of tree patchset for another cycle. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
