From: Dave Chinner <david@fromorbit.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Ross Zwisler <ross.zwisler@linux.intel.com>,
Nicholas Piggin <npiggin@gmail.com>, Jan Kara <jack@suse.cz>,
Jeff Moyer <jmoyer@redhat.com>, Yumei Huang <yuhuang@redhat.com>,
Michal Hocko <mhocko@suse.com>,
Xiaof Guangrong <guangrong.xiao@linux.intel.com>,
KVM list <kvm@vger.kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
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>,
Christoph Hellwig <hch@infradead.org>,
Linux MM <linux-mm@kvack.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)
Date: Thu, 22 Dec 2016 08:24:12 +1100 [thread overview]
Message-ID: <20161221212412.GB4758@dastard> (raw)
In-Reply-To: <CAPcyv4g3sgQ=Lh99RP7V5g-okgdC=BaeW8oLtHRfwU1gmh07=A@mail.gmail.com>
On Wed, Dec 21, 2016 at 08:53:46AM -0800, Dan Williams wrote:
> On Tue, Dec 20, 2016 at 4:40 PM, Darrick J. Wong
> <darrick.wong@oracle.com> wrote:
> > On Mon, Dec 19, 2016 at 05:18:40PM -0800, Dan Williams wrote:
> >> On Mon, Dec 19, 2016 at 5:09 PM, Darrick J. Wong
> >> <darrick.wong@oracle.com> wrote:
> >> > On Mon, Dec 19, 2016 at 02:11:49PM -0700, Ross Zwisler wrote:
> >> >> On Fri, Sep 16, 2016 at 03:54:05PM +1000, Nicholas Piggin wrote:
> >> >> <>
> >> >> > Definitely the first step would be your simple preallocated per
> >> >> > inode approach until it is shown to be insufficient.
> >> >>
> >> >> Reviving this thread a few months later...
> >> >>
> >> >> Dave, we're interested in taking a serious look at what it would take to get
> >> >> PMEM_IMMUTABLE working. Do you still hold the opinion that this is (or could
> >> >> become, with some amount of work) a workable solution?
> >> >>
> >> >> We're happy to do the grunt work for this feature, but we will probably need
> >> >> guidance from someone with more XFS experience. With you out on extended leave
> >> >> the first half of 2017, who would be the best person to ask for this guidance?
> >> >> Darrick?
> >> >
> >> > Yes, probably. :)
> >> >
> >> > I think where we left off with this (on the XFS side) is some sort of
> >> > fallocate mode that would allocate blocks, zero them, and then set the
> >> > DAX and PMEM_IMMUTABLE on-disk inode flags. After that, you'd mmap the
> >> > file and thereby gain the ability to control write persistents behavior
> >> > without having to worry about fs metadata updates. As an added plus, I
> >> > think zeroing the pmem also clears media errors, or something like that.
> >> >
> >> > <shrug> Is that a reasonable starting point? My memory is a little foggy.
> >> >
> >> > Hmm, I see Dan just posted something about blockdev fallocate. I'll go
> >> > read that.
> >>
> >> That's for device-dax, which is basically a poor man's PMEM_IMMUTABLE
> >> via a character device interface. It's useful for cases where you want
> >> an entire nvdimm namespace/volume in "no fs-metadata to worry about"
> >> mode. But, for sub-allocations of a namespace and support for
> >> existing tooling, PMEM_IMMUTABLE is much more usable.
> >
> > Well sure... but otoh I was thinking that it'd be pretty neat if we
> > could use the same code regardless of whether the target file was a
> > dax-device or an xfs file:
> >
> > fd = open("<some path>", O_RDWR);
> > fstat(fd, &statbuf):
> > fallocate(fd, FALLOC_FL_PMEM_IMMUTABLE, 0, statbuf.st_size);
> > p = mmap(NULL, statbuf.st_size, PROT_READ | PROT_WRITE, fd, 0);
> >
> > *(p + 42) = 0xDEADBEEF;
> > asm { clflush; } /* or whatever */
> >
> > ...so perhaps it would be a good idea to design the fallocate primitive
> > around "prepare this fd for mmap-only pmem semantics" and let it the
> > backend do zeroing and inode flag changes as necessary to make it
> > happen. We'd need to do some bikeshedding about what the other falloc
> > flags mean when we're dealing with pmem files and devices, but I think
> > we should try to keep the userland presentation the same unless there's
> > a really good reason not to.
>
> It would be interesting to use fallocate to size device-dax files...
No. device-dax needs to die, not poison a bunch of existing file and
block device APIs and behaviours with special snowflakes. Get
DAX-enabled filesystems to do what you need, and get rid of this
ugly, nasty hack.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-12-21 21:24 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
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 [this message]
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=20161221212412.GB4758@dastard \
--to=david@fromorbit.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=dave.hansen@intel.com \
--cc=gleb@kernel.org \
--cc=guangrong.xiao@linux.intel.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.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=npiggin@gmail.com \
--cc=pbonzini@redhat.com \
--cc=ross.zwisler@linux.intel.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).