On Tue, Mar 08, 2016 at 03:16:02PM +1100, Dave Chinner wrote: > This isn't all of the rmap functionality. It's patches up to the > point where I've come across the first piece that needs to be > reworked (the rmap intent execution code), so there's no point > holding these back until I've sorted that out. This builds on top of > for-next and the patch set I posted yesterday. > > Darrick, I've changed the authorship of the patches to reflect > the original series this has come from - can you check to see if > there's anything I got wrong when I did that? I'll come some minor bits on the actual patches, but I'd like to understand a few fundamental things first: For one Darrick has introduced a new rmapxbt btree recently, which allows using a rmap on reflink enabled file systems. In his tree we thus have two different implementation of a reverse mapping btree. Is there any good reason to keep it this way? For one reflinks are a compelling feature that I doubt people want to disable in the long run, so most filesystem will be using rmapxbt. I also don't think having these two implementations is good for the testing matrix in the long run. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
