All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jane Chu <jane.chu@oracle.com>
To: david@fromorbit.com, djwong@kernel.org, dan.j.williams@intel.com,
	hch@infradead.org, vishal.l.verma@intel.com,
	dave.jiang@intel.com, agk@redhat.com, snitzer@redhat.com,
	dm-devel@redhat.com, ira.weiny@intel.com, willy@infradead.org,
	vgoyal@redhat.com, linux-fsdevel@vger.kernel.org,
	nvdimm@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org
Subject: [PATCH v2 0/2] Dax poison recovery
Date: Fri,  5 Nov 2021 19:16:36 -0600	[thread overview]
Message-ID: <20211106011638.2613039-1-jane.chu@oracle.com> (raw)

Up till now, the method commonly used for data recovery from
dax media error has been a combination of hole-punch followed
by a pwrite(2). The downside of this method is that it causes
fragmentation of the pmem backend, which brings a host of
very challenging issues.

This patch is an attempt to provide an alternative way for
dax users to perform data recovery from pmem media error without
fragmenting the pmem backend.

Dax media error may be manifested to user process via SIGBUS
with .si_code BUS_MCEERR_AR when a load instruction consumes
a poison in the media, or SIGBUS with .si_code BUS_ADRERR when
a page fault handler fails to resolve due to existing poison
record, or IO error returned from a block read or write.

With the patch in place, the way for user process to recover
the data can be just a pwrite(2) to a page aligned range without
the need to punch-a-hole. In case of BUS_MCEERR_AR, the range
is incidated by the signal payload: .si_addr and .si_addr_lsb.
In case of BUS_ADRERR, the range is the user mapping page size
starting from .si_addr. If the clue of media error come from
block IO error, the range is a stretch of the block IO range
to page aligned range.

Changes from v1:
- instead of giving user the say to start dax data recovery,
  let dax-filesystem decide when to enter data recovery mode.
  Hence 99% of the non-dax usage of pwrite and its variants
  aren't aware of dax specific recovering.
- Instead of exporting dax_clear_error() API that does one thing,
  combine dax {poison-clearing, error-record-update, writing-good-data}
  in one tight operation to better protect data integrity.
- some semantics and format fixes

v1: 
https://lore.kernel.org/lkml/20211029223233.GB449541@dread.disaster.area/T/
  
Jane Chu (2):
  dax: Introduce normal and recovery dax operation modes
  dax,pmem: Implement pmem based dax data recovery

 drivers/dax/super.c             | 15 +++---
 drivers/md/dm-linear.c          | 14 +++---
 drivers/md/dm-log-writes.c      | 19 +++++---
 drivers/md/dm-stripe.c          | 14 +++---
 drivers/md/dm-target.c          |  2 +-
 drivers/md/dm-writecache.c      |  8 +--
 drivers/md/dm.c                 | 16 +++---
 drivers/nvdimm/pmem.c           | 86 +++++++++++++++++++++++++++++----
 drivers/nvdimm/pmem.h           |  2 +-
 drivers/s390/block/dcssblk.c    | 13 +++--
 fs/dax.c                        | 32 +++++++++---
 fs/fuse/dax.c                   |  4 +-
 fs/fuse/virtio_fs.c             | 12 +++--
 include/linux/dax.h             | 18 ++++---
 include/linux/device-mapper.h   |  5 +-
 tools/testing/nvdimm/pmem-dax.c |  2 +-
 16 files changed, 187 insertions(+), 75 deletions(-)

-- 
2.18.4


WARNING: multiple messages have this Message-ID (diff)
From: Jane Chu <jane.chu@oracle.com>
To: david@fromorbit.com, djwong@kernel.org, dan.j.williams@intel.com,
	hch@infradead.org, vishal.l.verma@intel.com,
	dave.jiang@intel.com, agk@redhat.com, snitzer@redhat.com,
	dm-devel@redhat.com, ira.weiny@intel.com, willy@infradead.org,
	vgoyal@redhat.com, linux-fsdevel@vger.kernel.org,
	nvdimm@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org
Subject: [dm-devel] [PATCH v2 0/2] Dax poison recovery
Date: Fri,  5 Nov 2021 19:16:36 -0600	[thread overview]
Message-ID: <20211106011638.2613039-1-jane.chu@oracle.com> (raw)

Up till now, the method commonly used for data recovery from
dax media error has been a combination of hole-punch followed
by a pwrite(2). The downside of this method is that it causes
fragmentation of the pmem backend, which brings a host of
very challenging issues.

This patch is an attempt to provide an alternative way for
dax users to perform data recovery from pmem media error without
fragmenting the pmem backend.

Dax media error may be manifested to user process via SIGBUS
with .si_code BUS_MCEERR_AR when a load instruction consumes
a poison in the media, or SIGBUS with .si_code BUS_ADRERR when
a page fault handler fails to resolve due to existing poison
record, or IO error returned from a block read or write.

With the patch in place, the way for user process to recover
the data can be just a pwrite(2) to a page aligned range without
the need to punch-a-hole. In case of BUS_MCEERR_AR, the range
is incidated by the signal payload: .si_addr and .si_addr_lsb.
In case of BUS_ADRERR, the range is the user mapping page size
starting from .si_addr. If the clue of media error come from
block IO error, the range is a stretch of the block IO range
to page aligned range.

Changes from v1:
- instead of giving user the say to start dax data recovery,
  let dax-filesystem decide when to enter data recovery mode.
  Hence 99% of the non-dax usage of pwrite and its variants
  aren't aware of dax specific recovering.
- Instead of exporting dax_clear_error() API that does one thing,
  combine dax {poison-clearing, error-record-update, writing-good-data}
  in one tight operation to better protect data integrity.
- some semantics and format fixes

v1: 
https://lore.kernel.org/lkml/20211029223233.GB449541@dread.disaster.area/T/
  
Jane Chu (2):
  dax: Introduce normal and recovery dax operation modes
  dax,pmem: Implement pmem based dax data recovery

 drivers/dax/super.c             | 15 +++---
 drivers/md/dm-linear.c          | 14 +++---
 drivers/md/dm-log-writes.c      | 19 +++++---
 drivers/md/dm-stripe.c          | 14 +++---
 drivers/md/dm-target.c          |  2 +-
 drivers/md/dm-writecache.c      |  8 +--
 drivers/md/dm.c                 | 16 +++---
 drivers/nvdimm/pmem.c           | 86 +++++++++++++++++++++++++++++----
 drivers/nvdimm/pmem.h           |  2 +-
 drivers/s390/block/dcssblk.c    | 13 +++--
 fs/dax.c                        | 32 +++++++++---
 fs/fuse/dax.c                   |  4 +-
 fs/fuse/virtio_fs.c             | 12 +++--
 include/linux/dax.h             | 18 ++++---
 include/linux/device-mapper.h   |  5 +-
 tools/testing/nvdimm/pmem-dax.c |  2 +-
 16 files changed, 187 insertions(+), 75 deletions(-)

-- 
2.18.4

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


             reply	other threads:[~2021-11-06  1:17 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-06  1:16 Jane Chu [this message]
2021-11-06  1:16 ` [dm-devel] [PATCH v2 0/2] Dax poison recovery Jane Chu
2021-11-06  1:16 ` [PATCH v2 1/2] dax: Introduce normal and recovery dax operation modes Jane Chu
2021-11-06  1:16   ` [dm-devel] " Jane Chu
2021-11-06  1:50   ` Darrick J. Wong
2021-11-06  1:50     ` [dm-devel] " Darrick J. Wong
2021-11-08 20:43     ` Jane Chu
2021-11-08 20:43       ` [dm-devel] " Jane Chu
2021-11-06 16:48   ` Dan Williams
2021-11-06 16:48     ` [dm-devel] " Dan Williams
2021-11-08 21:02     ` Jane Chu
2021-11-08 21:02       ` [dm-devel] " Jane Chu
2021-11-09  5:26       ` Ira Weiny
2021-11-09  5:26         ` [dm-devel] " Ira Weiny
2021-11-09  6:04         ` Dan Williams
2021-11-09  6:04           ` [dm-devel] " Dan Williams
2021-11-06  1:16 ` [PATCH v2 2/2] dax,pmem: Implement pmem based dax data recovery Jane Chu
2021-11-06  1:16   ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Jane Chu
2021-11-06  2:04   ` [PATCH v2 2/2] dax,pmem: " Darrick J. Wong
2021-11-06  2:04     ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Darrick J. Wong
2021-11-08 20:53     ` [PATCH v2 2/2] dax,pmem: " Jane Chu
2021-11-08 20:53       ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Jane Chu
2021-11-08 21:00     ` [PATCH v2 2/2] dax,pmem: " Jane Chu
2021-11-08 21:00       ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Jane Chu
2021-11-09  7:27   ` [PATCH v2 2/2] dax,pmem: " Christoph Hellwig
2021-11-09  7:27     ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Christoph Hellwig
2021-11-09 18:48     ` [PATCH v2 2/2] dax,pmem: " Dan Williams
2021-11-09 18:48       ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Dan Williams
2021-11-09 19:52       ` [PATCH v2 2/2] dax,pmem: " Christoph Hellwig
2021-11-09 19:52         ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Christoph Hellwig
2021-11-09 19:58       ` [PATCH v2 2/2] dax,pmem: " Jane Chu
2021-11-09 19:58         ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Jane Chu
2021-11-09 21:02         ` [PATCH v2 2/2] dax,pmem: " Dan Williams
2021-11-09 21:02           ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Dan Williams
2021-11-10 18:26           ` [PATCH v2 2/2] dax,pmem: " Jane Chu
2021-11-10 18:26             ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Jane Chu
2021-11-12 15:36             ` [PATCH v2 2/2] dax,pmem: " Mike Snitzer
2021-11-12 15:36               ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Mike Snitzer
2021-11-12 18:00               ` [PATCH v2 2/2] dax,pmem: " Jane Chu
2021-11-12 18:00                 ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Jane Chu
2021-11-09 19:14     ` [PATCH v2 2/2] dax,pmem: " Jane Chu
2021-11-09 19:14       ` [dm-devel] [PATCH v2 2/2] dax, pmem: " Jane Chu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211106011638.2613039-1-jane.chu@oracle.com \
    --to=jane.chu@oracle.com \
    --cc=agk@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=ira.weiny@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=snitzer@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.