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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
