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
next reply other threads:[~2021-11-06 1:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-06 1:16 Jane Chu [this message]
2021-11-06 1:16 ` [PATCH v2 1/2] dax: Introduce normal and recovery dax operation modes Jane Chu
2021-11-06 1:50 ` Darrick J. Wong
2021-11-08 20:43 ` Jane Chu
2021-11-06 16:48 ` Dan Williams
2021-11-08 21:02 ` Jane Chu
2021-11-09 5:26 ` Ira Weiny
2021-11-09 6:04 ` Dan Williams
2021-11-06 1:16 ` [PATCH v2 2/2] dax,pmem: Implement pmem based dax data recovery Jane Chu
2021-11-06 2:04 ` Darrick J. Wong
2021-11-08 20:53 ` Jane Chu
2021-11-08 21:00 ` Jane Chu
2021-11-09 7:27 ` Christoph Hellwig
2021-11-09 18:48 ` Dan Williams
2021-11-09 19:52 ` Christoph Hellwig
2021-11-09 19:58 ` Jane Chu
2021-11-09 21:02 ` Dan Williams
2021-11-10 18:26 ` Jane Chu
2021-11-12 15:36 ` Mike Snitzer
2021-11-12 18:00 ` Jane Chu
2021-11-09 19:14 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).