At 06/21/2016 12:03 AM, David Sterba wrote:

Hi,

I'm looking how well does this patchset merges with the rest, so far
there are excpected conflicts with Chandan's subpage-blocksize
patchset. For the easy parts, we can add stub patches to extend
functions like cow_file_range with parameters that are added by the
other patch.

Honestly I don't know which patchset to take first. As the
subpage-blockszie is in the core, there are no user visibility and
interface questions, but it must not cause any regressions.

Dedupe is optional, not default, and we have to mainly make sure it does
not have any impact when turned off.

So I see three possible ways:

* merge subpage first, as it defines the API, adapt dedupe

Personally, I'd like to merge subpage first.

AFAIK, it's more important than dedupe.
It affects whether a fs created in 64K page size environment can be 
mounted on a 4K page size system.

And further more, dedupe is still not in the ready-to-be-merged status.

The main undetermined part is ioctl interface.
I'm still working on the state-ful ioctl interface(use -f option to be 
stateless), along with some minor change to allow easy extension.
(To allow user-space caller to know exactly what optional parameter is 
not supported, for later dedeup rate accounting and other things)

And Wang and I are waiting for feedback for V11 patchset.
The latest ENOSPC fix may need another version to address such feedback.

And further more, for dedupe, it's quite easy to avoid any possible 
problem related to sectorsize change.

Just increase minimal dedupe blocksize to maximum sectorsize(64K), then
possible conflicts would be solved.

Thanks,
Qu

* merge dedupe first, as it only enhanced existing API, adapt subpage
* create a common branch for both, merge relevant parts of each
  patchset, add more patches to prepare common ground for either patch

You can deduce yourself which vairant poses work on who. My preference
is to do the 3rd variant, as it does not force us any particular merge
order.