Dan Williams writes:
> On Wed, Apr 11, 2018 at 9:06 AM, Jeff Moyer wrote:
>> Christoph Hellwig writes:
>>
>>> On Fri, Apr 06, 2018 at 03:41:39PM -0700, Dan Williams wrote:
Yes, but the trust interface definition is what is missing, especially
when we consider memmap=ss!nn and qemu-kvm
On Wed, Apr 11, 2018 at 9:06 AM, Jeff Moyer wrote:
> Christoph Hellwig writes:
>
>> On Fri, Apr 06, 2018 at 03:41:39PM -0700, Dan Williams wrote:
>>> Yes, but the trust interface definition is what is missing, especially
>>> when we consider memmap=ss!nn and qemu-kvm. For example do we turn off
>
Christoph Hellwig writes:
> On Fri, Apr 06, 2018 at 03:41:39PM -0700, Dan Williams wrote:
>> Yes, but the trust interface definition is what is missing, especially
>> when we consider memmap=ss!nn and qemu-kvm. For example do we turn off
>> DAX and/or MAP_SYNC on all platforms that don't provide
On Fri, Apr 06, 2018 at 03:41:39PM -0700, Dan Williams wrote:
> Yes, but the trust interface definition is what is missing, especially
> when we consider memmap=ss!nn and qemu-kvm. For example do we turn off
> DAX and/or MAP_SYNC on all platforms that don't provide a positive "I
> have ADR" indicat
On Fri, Apr 6, 2018 at 12:03 AM, Christoph Hellwig wrote:
> On Thu, Apr 05, 2018 at 03:17:17PM -0700, Dan Williams wrote:
>> > 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.
>>
>> Makes
On Thu, Apr 05, 2018 at 03:17:17PM -0700, Dan Williams wrote:
> > 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.
>
> Makes sense, we won't pursue *sync() support on device-dax it doesn't
On Thu, Apr 5, 2018 at 1:01 AM, Christoph Hellwig wrote:
> 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 requireme
On Thu, Apr 05, 2018 at 10:59:10AM -0400, Jeff Moyer wrote:
> So, I also hate this (note that this is already in place today for fs
> dax). You have an operation to make things persistent, and another one
> to *really* make things persistent. It makes no sense to me. I have no
> idea how to comm
Christoph Hellwig writes:
> 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 dev
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
On Thu, Apr 5, 2018 at 12:23 AM, Christoph Hellwig wrote:
> On Wed, Apr 04, 2018 at 05:03:07PM -0700, Dan Williams wrote:
>> "Currently, fsdax applications can assume that if they call fsync or
>> msync on a dax mapped file that any pending writes that have been
>> flushed out of the cpu cache wil
On Wed, Apr 04, 2018 at 05:03:07PM -0700, Dan Williams wrote:
> "Currently, fsdax applications can assume that if they call fsync or
> msync on a dax mapped file that any pending writes that have been
> flushed out of the cpu cache will be also be flushed to the lowest
> possible persistence / fail
Include lkml on the next posting as well.
On Wed, Apr 4, 2018 at 3:01 PM, Dave Jiang wrote:
> When msync() is called on a device dax region, eventually ops->fsync() is
> called. By providing fsync in the device dax file operations, we can provide
> support for both. nvdimm_flush() for the nd_regi
13 matches
Mail list logo
