All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-nvdimm <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH] dax: adding fsync/msync support for device DAX
Date: Thu, 5 Apr 2018 01:01:18 -0700	[thread overview]
Message-ID: <20180405080118.GA32396@infradead.org> (raw)
In-Reply-To: <CAPcyv4jn2DHu9HGH=XPr9VHP0gyENFKEiXr=w5hO2UR_tRWc0A@mail.gmail.com>

On Thu, Apr 05, 2018 at 12:56:02AM -0700, Dan Williams wrote:
> Yes, I think it is unfortunate that the failure mode is exposed to
> software at all. The problem is that ADR is a platform feature that
> depends on power supply requirements external to the NVDIMM device. An
> SSD is different. It is a self contained system that can arrange for
> the whole device to fail if the internal energy source fails and
> otherwise hide this detail from software. My personal take, a system
> designer that can specify and qualify an entire stack of components
> can certainly opt-out of advertising the flush capability to the OS
> because, like the SSD vendor, they control the integrated solution. A
> platform vendor that allows off the shelf power supplies would in my
> opinion be remiss not to give the OS the option to mitigate the
> quality of some random power supply. It then follow that if the OS has
> the ability to mitigate ADR failure it should be through a common
> interface between fsdax and devdax.

That means IFF ADR can fail like this we can't treat it as stable
storage and we must not support MAP_SYNC or equivalent device dax
behavior, period.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

  reply	other threads:[~2018-04-05  8:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04 22:01 [PATCH] dax: adding fsync/msync support for device DAX Dave Jiang
2018-04-05  0:03 ` Dan Williams
2018-04-05  7:23   ` Christoph Hellwig
2018-04-05  7:56     ` Dan Williams
2018-04-05  8:01       ` Christoph Hellwig [this message]
2018-04-05 14:59         ` Jeff Moyer
2018-04-05 15:10           ` Christoph Hellwig
2018-04-05 22:17         ` Dan Williams
2018-04-06  7:03           ` Christoph Hellwig
2018-04-06 22:41             ` Dan Williams
2018-04-09  9:32               ` Christoph Hellwig
2018-04-11 16:06                 ` Jeff Moyer
2018-04-11 16:27                   ` Dan Williams
2018-04-11 17:27                     ` Jeff Moyer

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=20180405080118.GA32396@infradead.org \
    --to=hch@infradead.org \
    --cc=dan.j.williams@intel.com \
    --cc=linux-nvdimm@lists.01.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.