On 4/11/2022 4:55 PM, Dan Williams wrote: > On Wed, Apr 6, 2022 at 10:31 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >> >> On Wed, Apr 06, 2022 at 05:32:31PM +0000, Jane Chu wrote: >>> Yes, I believe Dan was motivated by avoiding the dm dance as a result of >>> adding .recovery_write to dax_operations. >>> >>> I understand your point about .recovery_write is device specific and >>> thus not something appropriate for device agnostic ops. >>> >>> I can see 2 options so far - >>> >>> 1) add .recovery_write to dax_operations and do the dm dance to hunt >>> down to the base device that actually provides the recovery action >> >> That would be my preference. But I'll wait for Dan to chime in. > > Yeah, so the motivation was avoiding plumbing recovery through stacked > lookups when the recovery is specific to a pfn and the provider of > that pfn, but I also see it from Christoph's perspective that the only > agent that cares about recovery is the fsdax I/O path. Certainly > having ->dax_direct_access() take a DAX_RECOVERY flag and the op > itself go through the pgmap is a confusing split that I did not > anticipate when I made the suggestion. Since that flag must be there, > then the ->recovery_write() should also stay relative to a dax device. > > Apologies for the thrash Jane. > > One ask though, please separate plumbing the new flag argument to > ->dax_direct_access() and plumbing the new operation into preparation > patches before filling them in with the new goodness. Okay, will do in next revision. thanks! -jane
