Re: [PATCH v11 00/13] Btrfs dedupe framework
From: David Sterba <hidden>
Date: 2016-06-21 09:34:29
On Tue, Jun 21, 2016 at 05:26:23PM +0800, Qu Wenruo wrote:
quoted
Yeah, but I'm now concerned about the way both will be integrated in the development or preview branches, not really the functionality itself. Now the conflicts are not trivial, so this takes extra time on my side and I can't be sure about the result in the end if I put only minor efforts to resolve the conflicts ("make it compile"). And I don't want to do that too often. As stated in past discussions, the features of this impact should spend one development cycle in for-next, even if it's not ready for merge or there are reviews going on. The subpage patchset is now in a relatively good shape to start actual testing, which already revealed some problems.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.