linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: "Elliott\, Robert \(Persistent Memory\)" <elliott@hpe.com>,
	Ted Tso <tytso@mit.edu>,
	"linux-nvdimm\@lists.01.org" <linux-nvdimm@ml01.01.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xfs\@oss.sgi.com" <xfs@oss.sgi.com>,
	"adilger.kernel\@dilger.ca" <adilger.kernel@dilger.ca>,
	Cholerae Hu <choleraehyq@gmail.com>,
	"linux-ext4\@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: A blocksize problem about dax and ext4
Date: Fri, 08 Jan 2016 12:22:40 -0500	[thread overview]
Message-ID: <x49k2nk0yvz.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <20151224000021.GU19802@dastard> (Dave Chinner's message of "Thu, 24 Dec 2015 11:00:21 +1100")

Dave Chinner <david@fromorbit.com> writes:

>> 1. ext4 fails to mount the filesystem, while xfs just disables DAX.
>> It seems like they should they be the same.

I agree, it would be nice if they were the same.

> I don't really care what is done to ext4 here, but I'm not changing
> XFS behaviour. I'm expecting mixed dax/non-dax fileystems to be a
> thing, with DAX turned on by an inode flag on disk. Indeed, I see
> the mount option going away permanently for XFS, and DAX being
> controlled completely from on-disk flags. E.g. ext4 encrypted files
> need to turn off DAX, while clear text files can be accessed using
> DAX. This should happen completely transparently to the user....

The one thing we definitely need is a common way for an application to
open a file in dax mode.  So, whatever ends up being the interface for
xfs in the future sure as heck better work for ext4.

I'm also not super keen on just getting rid of the dax mount option.  I
understand why you'd want to do that, but I think it should stay, with
documentation on when you simply won't get dax mappings.

Please think about the poor programmers and system administrators that
have to use these interfaces.

Thanks,
Jeff

      parent reply	other threads:[~2016-01-08 17:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAM=YXF-aXxp19=uFDExUswpEfKXNN6LJScxAB-7-u-AgRiXJ2g@mail.gmail.com>
     [not found] ` <CAPcyv4gYHuSWuugnELSO6B1rye+b89io3zJVUXwRt0wE1ZfPrA@mail.gmail.com>
2015-12-23 21:18   ` A blocksize problem about dax and ext4 Elliott, Robert (Persistent Memory)
2015-12-24  0:00     ` Dave Chinner
2015-12-24  0:34       ` Cholerae Hu
2015-12-24  0:58         ` Dan Williams
2015-12-24  2:36           ` Cholerae Hu
2015-12-24  2:47             ` Elliott, Robert (Persistent Memory)
2015-12-24  4:13               ` Cholerae Hu
2015-12-24 10:11               ` Christoph Hellwig
2015-12-24 12:26                 ` Elliott, Robert (Persistent Memory)
2016-01-08 17:22       ` Jeff Moyer [this message]

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=x49k2nk0yvz.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=choleraehyq@gmail.com \
    --cc=david@fromorbit.com \
    --cc=elliott@hpe.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=tytso@mit.edu \
    --cc=xfs@oss.sgi.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).