lkml.org 
[lkml]   [2021]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [dm-devel] [PATCH 0/6] dax poison recovery with RWF_RECOVERY_DATA flag
Date
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@lst.de/

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.

>
>> 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.
>
>> the 3-in-1 binding would always be
>> required though. Maybe that'll be an ongoing discussion?
>
> Yeah, let's cross that bridge when we come to it.
>
>> Comments? Suggestions?
>
> It sounds great to me!
>

Thanks! I'll send out an updated patchset when it's ready.

-jane


\
 
 \ /
  Last update: 2021-11-04 21:28    [W:0.104 / U:1.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site