On Thu, Nov 4, 2021 at 5:46 PM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > On Thu, Nov 4, 2021 at 1:27 PM Jane Chu <jane.chu@xxxxxxxxxx> wrote: > > > > On 11/4/2021 12:00 PM, Dan Williams wrote: > > > > >> > > >> If this understanding is in the right direction, then I'd like to > > >> propose below changes to > > >> dax_direct_access(), dax_copy_to/from_iter(), pmem_copy_to/from_iter() > > >> and the dm layer copy_to/from_iter, dax_iomap_iter(). > > >> > > >> 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". > > > > > >> 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/ > > > > I was referring to > > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dax-devirtualize > > that has not come out yet, I said early on that I'll rebase on it, > > but looks like we still need pmem_copy_to/from_iter(), so. > > Yeah, since the block-layer divorce gets rid of the old poison > clearing path, then we're back to pmem_copy_to_iter() (or something > like it) needing to pick up the slack for poison clearing. I do agree > it would be nice to clean up all the unnecessary boilerplate, but the > error-list coordination requires a driver specific callback. At least > the DAX_F_VIRTUAL flag can eliminate the virtiofs and fuse callbacks. Although, if error management is generically implemented relative to a 'struct dax_device' then there wouldn't be a need to call all the way back into the driver, and the cleanup could still move forward. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
