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: > > > > 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+. David, I can implement it. In my next post of the subpage-blocksize patchset, I will bring in this change. -- chandan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
