On Tue, Jun 21, 2016 at 10:25:19PM +0530, Chandan Rajendra wrote: > > > 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 ... > 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+. The other conflicts like conversion from PAGE_SIZE to the the block oriented iterations will be harder, but these are usually localized and can be resolved. We'll see if there are other options to reduce the clashes but at the moment it's stuck at the two functions. Does that explain it better? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
