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
next 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: linkBe 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.