lkml.org 
[lkml]   [2017]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH] dax: add badblocks check to Device DAX
Date
On Wed, 2017-05-03 at 08:52 -0700, Dan Williams wrote:
> On Wed, May 3, 2017 at 8:31 AM, Toshi Kani <toshi.kani@hpe.com>
> wrote:
> > This is a RFC patch for seeking suggestions.  It adds support of
> > badblocks check in Device DAX by using region-level badblocks list.
> > This patch is only briefly tested.
> >
> > device_dax is a well-isolated self-contained module as it calls
> > alloc_dax() with dev_dax, which is private to device_dax.  For
> > checking badblocks, it needs to call dax_pmem to check with
> > region-level badblocks.
> >
> > This patch attempts to keep device_dax self-contained.  It adds
> > check_error() to dax_operations, and dax_check_error() as a stub
> > with *dev_dax and *dev pointers to convey it to dax_pmem.  I am
> > wondering if this is the right direction, or we should change the
> > modularity to let dax_pmem call alloc_dax() with its dax_pmem (or
> > I completely missed something).
>
> The problem is that device-dax guarantees a given fault granularity.
> To make that guarantee we can't fallback from 1G or 2M mappings due
> to an error. We also can't reasonably go the other way and fail
> mappings that contain a badblock because that would change the blast
> radius of a media error to the fault size.

Does it mean we expect users to have CPUs with MCE recovery for Device
DAX? Can we add an attributes like allow error-check & fall-back?

Thanks,
-Toshi
\
 
 \ /
  Last update: 2017-05-03 18:09    [W:0.140 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site