On Fri, Apr 22, 2022 at 02:27:32PM -0700, Dan Williams wrote: > On Thu, Apr 21, 2022 at 12:47 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > On Wed, Apr 20, 2022 at 10:54:59PM -0700, Christoph Hellwig wrote: > > > On Thu, Apr 21, 2022 at 02:35:02PM +1000, Dave Chinner wrote: > > > > Sure, I'm not a maintainer and just the stand-in patch shepherd for > > > > a single release. However, being unable to cleanly merge code we > > > > need integrated into our local subsystem tree for integration > > > > testing because a patch dependency with another subsystem won't gain > > > > a stable commit ID until the next merge window is .... distinctly > > > > suboptimal. > > > > > > Yes. Which is why we've taken a lot of mm patchs through other trees, > > > sometimes specilly crafted for that. So I guess in this case we'll > > > just need to take non-trivial dependencies into the XFS tree, and just > > > deal with small merge conflicts for the trivial ones. > > > > OK. As Naoyo has pointed out, the first dependency/conflict Ruan has > > listed looks trivial to resolve. > > > > The second dependency, OTOH, is on a new function added in the patch > > pointed to. That said, at first glance it looks to be independent of > > the first two patches in that series so I might just be able to pull > > that one patch in and have that leave us with a working > > fsdax+reflink tree. > > > > Regardless, I'll wait to see how much work the updated XFS/DAX > > reflink enablement patchset still requires when Ruan posts it before > > deciding what to do here. If it isn't going to be a merge > > candidate, what to do with this patchset is moot because there's > > little to test without reflink enabled... > > I do have a use case for this work absent the reflink work. Recall we > had a conversation about how to communicate "dax-device has been > ripped away from the fs" events and we ended up on the idea of reusing > ->notify_failure(), but with the device's entire logical address range > as the notification span. That will let me unwind and delete the > PTE_DEVMAP infrastructure for taking extra device references to hold > off device-removal. Instead ->notify_failure() arranges for all active > DAX mappings to be invalidated and allow the removal to proceed > especially since physical removal does not care about software pins. Sure. My point is that if the reflink enablement isn't ready to go, then from an XFS POV none of this matters in this cycle and we can just leave the dependencies to commit via Andrew's tree. Hence by the time we get to the reflink enablement all the prior dependencies will have been merged and have stable commit IDs, and we can just stage this series and the reflink enablement as we normally would in the next cycle. However, if we don't get the XFS reflink dax enablement sorted out in the next week or two, then we don't need this patchset in this cycle. Hence if you still need this patchset for other code you need to merge in this cycle, then you're the poor schmuck that has to run the mm-tree conflict guantlet to get a stable commit ID for the dependent patches in this cycle, not me.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
