From: Christoph Hellwig <hch@infradead.org>
To: "Oliver O'Halloran" <oohall@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Yumei Huang <yuhuang@redhat.com>, Michal Hocko <mhocko@suse.com>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
KVM list <kvm@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
Gleb Natapov <gleb@kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
mtosatti@redhat.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)
Date: Mon, 12 Sep 2016 00:51:28 -0700 [thread overview]
Message-ID: <20160912075128.GB21474@infradead.org> (raw)
In-Reply-To: <CAOSf1CHaW=szD+YEjV6vcUG0KKr=aXv8RXomw9xAgknh_9NBFQ@mail.gmail.com>
On Mon, Sep 12, 2016 at 05:25:15PM +1000, Oliver O'Halloran wrote:
> What are the problems here? Is this a matter of existing filesystems
> being unable/unwilling to support this or is it just fundamentally
> broken?
It's a fundamentally broken model. See Dave's post that actually was
sent slightly earlier then mine for the list of required items, which
is fairly unrealistic. You could probably try to architect a file
system for it, but I doubt it would gain much traction.
> The end goal is to let applications manage the persistence of
> their own data without having to involve the kernel in every IOP, but
> if we can't do that then what would a 90% solution look like? I think
> most people would be OK with having to do an fsync() occasionally, but
> not after ever write to pmem.
You need an fsync for each write that you want to persist. This sounds
painful for now. But I have an implementation that will allow the
atomic commit of more or less arbitrary amounts of previous writes for
XFS that I plan to land once the reflink work is in.
That way you create almost arbitrarily complex data structures in your
programs and commit them atomicly. It's not going to fit the nvml
model, but that whole think has been complete bullshit since the
beginning anyway.
next prev parent reply other threads:[~2016-09-12 7:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-08 4:32 DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps) Dan Williams
2016-09-08 22:56 ` Ross Zwisler
2016-09-08 23:04 ` Dan Williams
2016-09-09 8:55 ` Xiao Guangrong
2016-09-09 15:40 ` Dan Williams
2016-09-12 6:00 ` Xiao Guangrong
2016-09-12 3:44 ` Rudoff, Andy
2016-09-12 6:31 ` Xiao Guangrong
2016-09-12 1:40 ` Dave Chinner
2016-09-15 5:55 ` Darrick J. Wong
2016-09-15 6:25 ` Dave Chinner
2016-09-12 5:27 ` Christoph Hellwig
2016-09-12 7:25 ` Oliver O'Halloran
2016-09-12 7:51 ` Christoph Hellwig [this message]
2016-09-12 8:05 ` Nicholas Piggin
2016-09-12 15:01 ` Christoph Hellwig
2016-09-13 1:31 ` Nicholas Piggin
2016-09-13 4:06 ` Dan Williams
2016-09-13 5:40 ` Nicholas Piggin
2016-09-12 21:34 ` Dave Chinner
2016-09-13 1:53 ` Nicholas Piggin
2016-09-13 7:17 ` Christoph Hellwig
2016-09-13 9:06 ` Nicholas Piggin
2016-09-14 7:39 ` Dave Chinner
2016-09-14 10:19 ` Nicholas Piggin
2016-09-15 2:31 ` Dave Chinner
2016-09-15 3:49 ` Nicholas Piggin
2016-09-15 10:32 ` Dave Chinner
2016-09-15 11:42 ` Nicholas Piggin
2016-09-15 22:33 ` Dave Chinner
2016-09-16 5:54 ` Nicholas Piggin
2016-12-19 21:11 ` Ross Zwisler
2016-12-20 1:09 ` Darrick J. Wong
2016-12-20 1:18 ` Dan Williams
2016-12-21 0:40 ` Darrick J. Wong
2016-12-21 16:53 ` Dan Williams
2016-12-21 21:24 ` Dave Chinner
2016-12-21 21:33 ` Dan Williams
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=20160912075128.GB21474@infradead.org \
--to=hch@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=gleb@kernel.org \
--cc=guangrong.xiao@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@ml01.01.org \
--cc=mhocko@suse.com \
--cc=mtosatti@redhat.com \
--cc=oohall@gmail.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=yuhuang@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).