From: Dan Williams <dan.j.williams@intel.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
Nicholas Piggin <npiggin@gmail.com>,
Dave Chinner <david@fromorbit.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: Wed, 21 Dec 2016 08:53:46 -0800 [thread overview]
Message-ID: <CAPcyv4g3sgQ=Lh99RP7V5g-okgdC=BaeW8oLtHRfwU1gmh07=A@mail.gmail.com> (raw)
In-Reply-To: <20161221004031.GF9865@birch.djwong.org>
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...
However, the fallocate userland presentation I was looking to unify
was the semantic for how to clear errors. The current method for
creating a device-dax instance is 'echo "<some size>" > "<some sysfs
file>"'. Christoph put the kibosh on carrying the
fallocate-error-clearing semantic over, so we'll need to fallback to
using the existing ND_IOCTL_CLEAR_ERROR. All that's missing for error
clearing is a secondary mechanism to report the media error list for a
physical address range.
next prev parent reply other threads:[~2016-12-21 16:53 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 [this message]
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='CAPcyv4g3sgQ=Lh99RP7V5g-okgdC=BaeW8oLtHRfwU1gmh07=A@mail.gmail.com' \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=darrick.wong@oracle.com \
--cc=dave.hansen@intel.com \
--cc=david@fromorbit.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).