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


Groups > linux.kernel > #1332438

Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems

From Dave Chinner <david@fromorbit.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems
Date 2016-02-12 00:50 +0100
Message-ID <r199L-7jD-7@gated-at.bofh.it> (permalink)
References (5 earlier) <r11lU-2aN-13@gated-at.bofh.it> <r16lA-5v2-13@gated-at.bofh.it> <r16vg-5ys-17@gated-at.bofh.it> <r18dI-6JX-11@gated-at.bofh.it> <r18np-6Ne-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Feb 11, 2016 at 02:59:14PM -0800, Dan Williams wrote:
> On Thu, Feb 11, 2016 at 2:46 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Thu, Feb 11, 2016 at 12:58:38PM -0800, Dan Williams wrote:
> >> On Thu, Feb 11, 2016 at 12:46 PM, Dave Chinner <david@fromorbit.com> wrote:
> >> Maybe I don't need to worry because it's already the case that a
> >> mmap of the raw device may not see the most up to date data for a
> >> file that has dirty fs-page-cache data.
> >
> > It goes both ways. What happens if mkfs or fsck modifies the
> > block device via mmap+DAX and then the filesystem mounts the block
> > device and tries to read that metadata via the block device page
> > cache?
> >
> > Quite frankly, DAX on the block device is a can of worms we really
> > don't need to deal with right now. IMO it's a solution looking for a
> > problem to solve,
> 
> Virtualization use cases want to give large ranges to guest-VMs, and
> it is currently the only way to reliably get 1GiB mappings.

Precisely my point - block devices are not the best way to solve
this problem.

A file, on XFS, with a 1GB extent size hint and preallocated to be
aligned to 1GB addresses (i.e. mkfs.xfs -d su=1G,sw=1 on the host
filesystem) will give reliable 1GB aligned blocks for DAX mappings,
just like a block device will. Peformance wise it's little different
to using the block device directly. Management wise it's way more
flexible, especially as such image files can be recycled for new VMs
almost instantly via FALLOC_FL_FLAG_ZERO_RANGE.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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


Thread

[PATCH v2 2/2] dax: move writeback calls into the filesystems Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-02-10 21:50 +0100
  Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dave Chinner <david@fromorbit.com> - 2016-02-10 23:10 +0100
    Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-02-10 23:50 +0100
      Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dave Chinner <david@fromorbit.com> - 2016-02-11 00:50 +0100
      Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Jan Kara <jack@suse.cz> - 2016-02-11 14:00 +0100
        Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dan Williams <dan.j.williams@intel.com> - 2016-02-11 16:30 +0100
          Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Jan Kara <jack@suse.cz> - 2016-02-11 17:30 +0100
          Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dave Chinner <david@fromorbit.com> - 2016-02-11 21:50 +0100
            Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dan Williams <dan.j.williams@intel.com> - 2016-02-11 22:00 +0100
              Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dave Chinner <david@fromorbit.com> - 2016-02-11 23:50 +0100
                Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dan Williams <dan.j.williams@intel.com> - 2016-02-12 00:00 +0100
                Re: [PATCH v2 2/2] dax: move writeback calls into the filesystems Dave Chinner <david@fromorbit.com> - 2016-02-12 00:50 +0100

csiph-web