Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1390554 > unrolled thread

[PATCH v4 0/7] dax: handling media errors

Back to article view | Back to linux.kernel

Contents

  [PATCH v4 0/7] dax: handling media errors Vishal Verma <vishal.l.verma@intel.com> - 2016-04-28 23:30 +0200
    [PATCH v4 2/7] dax: fallback from pmd to pte on error Vishal Verma <vishal.l.verma@intel.com> - 2016-04-28 23:30 +0200
    [PATCH v4 8/7] Documentation: add error handling information to dax.txt Vishal Verma <vishal.l.verma@intel.com> - 2016-04-30 00:00 +0200

#1390554 — [PATCH v4 0/7] dax: handling media errors

Until now, dax has been disabled if media errors were found on
any device. This series attempts to address that.

The first three patches from Dan re-enable dax even when media
errors are present.

The fourth patch from Matthew removes the zeroout path from dax
entirely, making zeroout operations always go through the driver
(The motivation is that if a backing device has media errors,
and we create a sparse file on it, we don't want the initial
zeroing to happen via dax, we want to give the block driver a
chance to clear the errors).

The fifth patch changes how DAX IO is re-routed as direct IO.
We add a new iocb flag for DAX to distinguish it from actual
direct IO, and if we're in O_DIRECT, use the regular direct_IO
path instead of DAX. This gives us an opportunity to do recovery
by doing O_DIRECT writes that will go through the driver to clear
errors from bad sectors.

Patch 6 reduces our calls to clear_pmem from dax in the
truncate/hole-punch cases. We check if the range being truncated
is sector aligned/sized, and if so, send blkdev_issue_zeroout
instead of clear_pmem so that errors can be handled better by
the driver.

Patch 7 fixes a redundant comment in DAX and is mostly unrelated
to the rest of this series.

This series also depends on/is based on Jan Kara's DAX Locking
fixes series [1].


[1]: http://www.spinics.net/lists/linux-mm/msg105819.html

v4:
 - Remove the dax->direct_IO fallbacks entirely. Instead, go through
   the usual direct_IO path when we're in O_DIRECT, and use dax_IO
   for other, non O_DIRECT IO. (Dan, Christoph)

v3:
 - Wrapper-ize the direct_IO fallback again and make an exception
   for -EIOCBQUEUED (Jeff, Dan)
 - Reduce clear_pmem usage in DAX to the minimum


Dan Williams (3):
  block, dax: pass blk_dax_ctl through to drivers
  dax: fallback from pmd to pte on error
  dax: enable dax in the presence of known media errors (badblocks)

Matthew Wilcox (1):
  dax: use sb_issue_zerout instead of calling dax_clear_sectors

Vishal Verma (3):
  fs: prioritize and separate direct_io from dax_io
  dax: for truncate/hole-punch, do zeroing through the driver if
    possible
  dax: fix a comment in dax_zero_page_range and dax_truncate_page

 arch/powerpc/sysdev/axonram.c | 10 +++---
 block/ioctl.c                 |  9 -----
 drivers/block/brd.c           |  9 ++---
 drivers/block/loop.c          |  2 +-
 drivers/nvdimm/pmem.c         | 17 +++++++---
 drivers/s390/block/dcssblk.c  | 12 +++----
 fs/block_dev.c                | 19 ++++++++---
 fs/dax.c                      | 78 +++++++++++++++----------------------------
 fs/ext2/inode.c               | 23 ++++++++-----
 fs/ext4/file.c                |  2 +-
 fs/ext4/inode.c               | 19 +++++++----
 fs/xfs/xfs_aops.c             | 20 +++++++----
 fs/xfs/xfs_bmap_util.c        | 15 +++------
 fs/xfs/xfs_file.c             |  4 +--
 include/linux/blkdev.h        |  3 +-
 include/linux/dax.h           |  1 -
 include/linux/fs.h            | 15 +++++++--
 mm/filemap.c                  |  4 +--
 18 files changed, 134 insertions(+), 128 deletions(-)

-- 
2.5.5

[toc] | [next] | [standalone]

#1390555 — [PATCH v4 2/7] dax: fallback from pmd to pte on error

From: Dan Williams <dan.j.williams@intel.com>

In preparation for consulting a badblocks list in pmem_direct_access(),
teach dax_pmd_fault() to fallback rather than fail immediately upon
encountering an error.  The thought being that reducing the span of the
dax request may avoid the error region.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 fs/dax.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 5a34f08..52f0044 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1111,8 +1111,8 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned long address,
 		long length = dax_map_atomic(bdev, &dax);
 
 		if (length < 0) {
-			result = VM_FAULT_SIGBUS;
-			goto out;
+			dax_pmd_dbg(&bh, address, "dax-error fallback");
+			goto fallback;
 		}
 		if (length < PMD_SIZE) {
 			dax_pmd_dbg(&bh, address, "dax-length too small");
-- 
2.5.5

[toc] | [prev] | [next] | [standalone]

#1391462 — [PATCH v4 8/7] Documentation: add error handling information to dax.txt

This just provides information of the basic paths that can be used to
deal with (i.e. clear) media errors from the file system point-of-view.

Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
---

While this isn't a design document for new mechanisms for adding
error recovery/redundancy at the block/fs layers, this attempts to
explain the bare essentials required for anything operating above
the pmem block driver in the stack.

 Documentation/filesystems/dax.txt | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt
index 7bde640..71cd8fa 100644
--- a/Documentation/filesystems/dax.txt
+++ b/Documentation/filesystems/dax.txt
@@ -79,6 +79,40 @@ These filesystems may be used for inspiration:
 - ext4: the fourth extended filesystem, see Documentation/filesystems/ext4.txt
 
 
+Handling Media Errors
+---------------------
+
+The libnvdimm subsystem stores a record of known media error locations for
+each pmem block device (in gendisk->badblocks). If we fault at such location,
+or one with a latent error not yet discovered, the application can expect
+to receive a SIGBUS. Libnvdimm also allows clearing of these errors by simply
+writing the affected sectors (through the pmem driver, and if the underlying
+NVDIMM supports the clear_poison DSM defined by ACPI).
+
+Since DAX IO normally doesn't go through the driver/bio path, applications or
+sysadmins have an option to restore the lost data from a prior backup/inbuilt
+redundancy in the following two ways:
+
+1. Delete the affected file, and restore from a backup (sysadmin route):
+   This will free the file system blocks that were being used by the file,
+   and the next time they're allocated, they will be zeroed first, which
+   happens through the driver, and will clear bad sectors.
+
+2. Open the file with O_DIRECT, and restore a sector's worth of data at the
+   bad location (application route):
+   We allow O_DIRECT writes to go through the normal O_DIRECT path that sends
+   bios down through the driver. If an application is able to restore its own
+   data, it can use this path to clear errors.
+
+These are the two basic paths that allow DAX filesystems to continue operating
+in the presence of media errors. More robust error recovery mechanisms can be
+built on top of this in the future, for example, involving redundancy/mirroring
+provided at the block layer through DM, or additionally, at the filesystem
+level. These would have to rely on the above two tenets, that error clearing
+can happen either by sending an IO through the driver, or zeroing (also through
+the driver).
+
+
 Shortcomings
 ------------
 
-- 
2.5.5

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web