On 2/3/2022 9:34 PM, Dan Williams wrote:
> On Fri, Jan 28, 2022 at 1:32 PM Jane Chu <jane.chu@xxxxxxxxxx> wrote:
>>
>> If one of the MD raid participating target dax device supports
>> DAXDEV_RECOVERY, then it'll be declared on the whole that the
>> MD device is capable of DAXDEV_RECOVERY.
>> And only when the recovery process reaches to the target driver,
>> it becomes deterministic whether a certain dax address range
>> maybe recovered, or not.
>>
>> Signed-off-by: Jane Chu <jane.chu@xxxxxxxxxx>
>> ---
>> drivers/md/dm-table.c | 33 +++++++++++++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
>> index e43096cfe9e2..8af8a81b6172 100644
>> --- a/drivers/md/dm-table.c
>> +++ b/drivers/md/dm-table.c
>> @@ -844,6 +844,36 @@ static bool dm_table_supports_dax(struct dm_table *t,
>> return true;
>> }
>>
>> +/* Check whether device is capable of dax poison recovery */
>> +static int device_poison_recovery_capable(struct dm_target *ti,
>> + struct dm_dev *dev, sector_t start, sector_t len, void *data)
>> +{
>> + if (!dev->dax_dev)
>> + return false;
>> + return dax_recovery_capable(dev->dax_dev);
>
> Hmm it's not clear to me that dax_recovery_capable is necessary. If a
> dax_dev does not support recovery it can simply fail the
> dax_direct_access() call with the DAX_RECOVERY flag set.
>
> So all DM needs to worry about is passing the new @flags parameter
> through the stack.
Yeah, given your idea about adding the .recovery_write to pgmap_ops, it
wouldn't be needed.
thanks,
-jane
