Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1672290

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

From Andy Lutomirski <luto@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem
Date 2017-06-22 06:10 +0200
Message-ID <tV1Bn-7PL-1@gated-at.bofh.it> (permalink)
References (6 earlier) <tUoqm-7jN-25@gated-at.bofh.it> <tUu2K-2t3-15@gated-at.bofh.it> <tUCWl-7XY-7@gated-at.bofh.it> <tUGdz-1Px-1@gated-at.bofh.it> <tUXR7-59P-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jun 21, 2017 at 5:02 PM, Dave Chinner <david@fromorbit.com> wrote:
>
> You seem to be calling the "fdatasync on every page fault" the

It's the opposite of fdatasync().  It needs to sync whatever metadata
is needed to find the data.  The data doesn't need to be synced.

> "lightweight" option. That's the brute-force-with-big-hammer
> solution - it's most definitely not lightweight as every page fault
> has extra overhead to call ->fsync(). Sure, the API is simple, but
> the runtime overhead is significant.

It's lightweight in terms of its impact on the filesystem.  It doesn't
need any persistent setup -- you can just use it.

> Even if you are considering the complexity of the APIs, it's hardly
> a "heavyweight" when it only requires a single call to fallocate()
> before mmap() to set up the immutable extents on the file...

So what would the exact semantics be?  In particular, how can it fail?
 If I do the fallocate(), is it absolutely promised that the extent
map won't get out of sync between what mmap sees and what's on disk?
Do user programs need to worry about colliding with each other when
one does fallocate() to DAXify a file and the other does fallocate()
to unDAXify a file?  Does this particular fallocate() call still keep
its effect after a reboot?

These issues are why I think it would be nicer to have an API that
makes a particular mapping or fd be unconditionally *correct* and then
to provide something else that makes it avoid latency spikes.

Is there an actual concrete proposal that's reviewable?

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-20 03:20 +0200
  Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-20 08:00 +0200
    Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for         byte-addressable updates to pmem Christoph Hellwig <hch@lst.de> - 2017-06-20 11:00 +0200
      Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dan Williams <dan.j.williams@intel.com> - 2017-06-20 18:20 +0200
        Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-20 18:30 +0200
        Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-21 02:00 +0200
          Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem "Darrick J. Wong" <darrick.wong@oracle.com> - 2017-06-21 03:30 +0200
            Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-21 04:30 +0200
    Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-20 12:20 +0200
      Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-20 18:20 +0200
        Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-21 03:50 +0200
          Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-21 07:20 +0200
            Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-22 02:10 +0200
              Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-22 06:10 +0200
                Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Dave Chinner <david@fromorbit.com> - 2017-06-23 03:10 +0200
                Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for  byte-addressable updates to pmem Andy Lutomirski <luto@kernel.org> - 2017-06-23 05:10 +0200

csiph-web