lkml.org 
[lkml]   [2021]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 0/3] dax: clear poison on the fly along pwrite
On Tue, Sep 14, 2021 at 4:32 PM Jane Chu <jane.chu@oracle.com> wrote:
>
> If pwrite(2) encounters poison in a pmem range, it fails with EIO.
> This is unecessary if hardware is capable of clearing the poison.
>
> Though not all dax backend hardware has the capability of clearing
> poison on the fly, but dax backed by Intel DCPMEM has such capability,
> and it's desirable to, first, speed up repairing by means of it;
> second, maintain backend continuity instead of fragmenting it in
> search for clean blocks.
>
> Jane Chu (3):
> dax: introduce dax_operation dax_clear_poison

The problem with new dax operations is that they need to be plumbed
not only through fsdax and pmem, but also through device-mapper.

In this case I think we're already covered by dax_zero_page_range().
That will ultimately trigger pmem_clear_poison() and it is routed
through device-mapper properly.

Can you clarify why the existing dax_zero_page_range() is not sufficient?

> dax: introduce dax_clear_poison to dax pwrite operation
> libnvdimm/pmem: Provide pmem_dax_clear_poison for dax operation
>
> drivers/dax/super.c | 13 +++++++++++++
> drivers/nvdimm/pmem.c | 17 +++++++++++++++++
> fs/dax.c | 9 +++++++++
> include/linux/dax.h | 6 ++++++
> 4 files changed, 45 insertions(+)
>
> --
> 2.18.4
>

\
 
 \ /
  Last update: 2021-09-15 06:45    [W:0.191 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site