linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Ross Zwisler <zwisler@kernel.org>, Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>, Jan Kara <jack@suse.cz>,
	linux-xfs <linux-xfs@vger.kernel.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/3] ext2, ext4, xfs: hard fail dax mount on unsupported devices
Date: Wed, 17 Oct 2018 17:31:09 -0400	[thread overview]
Message-ID: <x491s8ofeg2.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <116ef687-f23d-b45c-1b48-fd444b346719@sandeen.net> (Eric Sandeen's message of "Wed, 17 Oct 2018 14:42:36 -0500")

Eric Sandeen <sandeen@sandeen.net> writes:

> I've been thinking about the per-inode stuff a bit, and while I don't know
> how to resolve some of the trickier issues, at least the expected behavior
> seems like something we can narrow down and specify.
>
> Because it's an on-disk flag (in xfs today, in any case) it seems that
> the only sane behavior to expect is either/or, i.e.:
>
> Mount option: All files always dax, per-inode flags ignored (or rejected)
> Per-inode: Mount option cannot be specified; only inodes explicitly flagged are dax
>
> Think about it; what would mount-option-plus-per-inode mean?  We have
> no "negative" dax flag, so while mount-option-with-flag surely means
> "dax", what the heck does mount-option-without-flag mean, and how is it
> distinguishable from mount option only?
>
> I submit that flags can only have meaning w/o the fs-wide mount option
> enabled, so the question of "should we hard fail mount -o dax for devices
> that cannot support it" seems to be orthogonal to the per-inode question.
>
> i.e. mount -o dax really can only mean "I want dax on everything" and so
> again, I think we probably need to fail the mount if that can't be honored.

I hate to even open up this can of worms, but what about killing the dax
mount option?

To quote Christoph:
  How does an application "make use of DAX"?  What actual user visible
  semantics are associated with a file that has this flag set?

We're already talking about making caching decisions automatically, so
does DAX even mean anything at that point?  If the storage and the file
system support it, enable it.

>From what we've seen so far, aplications want:
1) to be able to make data persistent from userspace
   For this, we have MAP_SYNC.
2) to determine whether or not page cache will be used
   For this, we have O_DIRECT for read/write access, and MAP_SYNC for
   mmap access (and maybe a third option coming, we'll see).

The only thing users gain from a mount option is the ability to turn OFF
dax.  I suppose there might be a use case that wants this, but I'm not
aware of it.

Cheers,
Jeff

  parent reply	other threads:[~2018-10-18  5:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-08 19:32 [PATCH 0/3] ext2, ext4, xfs: hard fail dax mount on unsupported devices Eric Sandeen
2018-10-08 19:32 ` [PATCH 1/3] " Eric Sandeen
2018-10-08 22:10   ` Dave Chinner
2018-10-08 19:32 ` [PATCH 2/3] ext4: " Eric Sandeen
2018-12-04  5:48   ` Theodore Y. Ts'o
2018-10-08 19:32 ` [PATCH 3/3] ext2: " Eric Sandeen
2018-10-11 10:36 ` [PATCH 0/3] ext2, ext4, xfs: " Jan Kara
2018-10-11 18:08   ` Dan Williams
2018-10-11 18:38     ` Eric Sandeen
2018-10-12  2:21       ` Theodore Y. Ts'o
2018-10-12  8:21       ` Christoph Hellwig
2018-10-13 16:05         ` Ross Zwisler
2018-10-17 19:42           ` Eric Sandeen
2018-10-17 19:51             ` Ross Zwisler
2018-10-17 19:52             ` Dan Williams
2018-10-17 21:31             ` Jeff Moyer [this message]
2018-10-17 21:44               ` Dan Williams
2018-10-18  1:05                 ` Dave Chinner
2018-10-18  2:01                   ` 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=x491s8ofeg2.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --cc=zwisler@kernel.org \
    /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).