On Thu, Nov 04, 2021 at 12:00:12PM -0700, Dan Williams wrote: > > 1. dax_iomap_iter() rely on dax_direct_access() to decide whether there > > is likely media error: if the API without DAX_F_RECOVERY returns > > -EIO, then switch to recovery-read/write code. In recovery code, > > supply DAX_F_RECOVERY to dax_direct_access() in order to obtain > > 'kaddr', and then call dax_copy_to/from_iter() with DAX_F_RECOVERY. > > I like it. It allows for an atomic write+clear implementation on > capable platforms and coordinates with potentially unmapped pages. The > best of both worlds from the dax_clear_poison() proposal and my "take > a fault and do a slow-path copy". Fine with me as well. > > > 2. the _copy_to/from_iter implementation would be largely the same > > as in my recent patch, but some changes in Christoph's > > 'dax-devirtualize' maybe kept, such as DAX_F_VIRTUAL, obviously > > virtual devices don't have the ability to clear poison, so no need > > to complicate them. And this also means that not every endpoint > > dax device has to provide dax_op.copy_to/from_iter, they may use the > > default. > > Did I miss this series or are you talking about this one? > https://lore.kernel.org/all/20211018044054.1779424-1-hch@xxxxxx/ Yes. This is an early RFC, but I plan to finish this up and submit it after the updated decouple series. > > > I'm not sure about nova and others, if they use different 'write' other > > than via iomap, does that mean there will be need for a new set of > > dax_op for their read/write? > > No, they're out-of-tree they'll adjust to the same interface that xfs > and ext4 are using when/if they go upstream. Yepp.
