On Thursday, June 23, 2016 02:17:38 PM David Sterba wrote:

On Tue, Jun 21, 2016 at 10:25:19PM +0530, Chandan Rajendra wrote:

quoted

quoted

quoted

I'm completely OK to do the rebase, but since I don't have 64K page size 
machine to test the rebase, we can only test if 4K system is unaffected.

Although not much help, at least it would be better than making it compile.

Also such rebase may help us to expose bad design/unexpected corner case 
in dedupe.
So if it's OK, please let me try to do the rebase.

Well, if you base dedupe on subpage, then it could be hard to find the
patchset that introduces bugs, or combination of both. We should be able
to test the features independently, and thus I'm proposing to first find
some common patchset that makes that possible.

I am not sure if I understood the above statement correctly. Do you mean to
commit the 'common/simple' patches from both the subpage-blocksize & dedupe
patchset first and then bring in the complicated ones later?

That would be great yes, but ...

quoted

If yes, then we have a problem doing that w.r.t subpage-blocksize
patchset. The first few patches bring in the core changes necessary for the
other remaining patches.

... not easily possible. I looked again for common functions that change
the singature and found only cow_file_range and run_delalloc_nocow. The
plan:

- separate patch that adds new parameters required by both patches to
  the functions
- update all call sites, add 0/NULL as defaults for the new unused
  parameters
- rebase both patches on top of this patch

How does this help: if a patch starts to use the new parameter, it
changes only the value at all call sites. This is much easier to verify
and merge manually compared to adding a new parameter to the middle of
the list, namely when the functions take 6+.

David, I can implement it. In my next post of the subpage-blocksize patchset, I
will bring in this change.


-- 
chandan