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.
|