All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>, linux-ext4@vger.kernel.org
Cc: Lukas Czerner <lczerner@redhat.com>
Subject: Re: [PATCH] ext4: introduce per-inode DAX flag
Date: Thu, 24 Aug 2017 14:20:57 -0400	[thread overview]
Message-ID: <20170824182057.amdirlrbugezrahy@thunk.org> (raw)
In-Reply-To: <20170811134130.o46y5jpekrpj5qvw@rh_laptop>

On Fri, Aug 11, 2017 at 03:41:30PM +0200, Lukas Czerner wrote:
> > > That said, it seems to me that there can be some user choice involved in
> > > this at least based on the fact that when DAX is used system memory is not
> > > used.
> > 
> > All of the above are charateristics of the medium, not of the
> > application.

So it seems that Cristoph's primary object to using a per-inode DAX
flag is that it is a not-very-well-defined hint to the file system
about how to treat writes for a class of storage devices which do not
yet have (and perhaps may never have) a standard set of performance
characteristics.  So if we encode this into the file system format,
we'll be stuck with a "do something different" set of semantics that
xfs (and ext4 if we pick up this patch) will have to support forever.

Or, at least, if we make changes that cause performance impact to
userspace applications, this may cause application programmers to
kvetch --- not that they never done *that* before.  :-)

The counter-argument is that system administrators do need to have a
way to signal that they would like the file system to "do something
different" on a per-file basis, and no one else has come up with
another way of doing things.  Furthermore, it would be highly
desirable if the system adminisator can provide this per-file system
hint with requiring changes to the application.  (For example, by
adding madvise/fadvise hints.)

Is that a fair summary of the argument?

I have two additional questions I'd like to ask at this point.

1)  Has there been any other difficulty that XFS has had due to the
fact that they have this DAX flag added?  e.g., are there any
operational, or practical code maintainability issues at stake here?
Or is this mostly an design philosophy debate?

2) Are there any users using the DAX flag with XFS such that, if XFS
were to remove the DAX flag support, those users would complain
bitterly?

Thanks,

					- Ted

  reply	other threads:[~2017-08-24 18:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-02 16:09 [PATCH] ext4: introduce per-inode DAX flag Lukas Czerner
2017-08-05  8:46 ` Christoph Hellwig
2017-08-07 12:12   ` Lukas Czerner
2017-08-08  9:00     ` Lukas Czerner
2017-08-11 10:01       ` Christoph Hellwig
2017-08-11 12:11         ` Lukas Czerner
2017-08-11 12:58           ` Christoph Hellwig
2017-08-11 13:41             ` Lukas Czerner
2017-08-24 18:20               ` Theodore Ts'o [this message]
2017-08-25  7:54                 ` Christoph Hellwig
2017-08-25 15:14                   ` Theodore Ts'o
2017-08-25 15:40                     ` Christoph Hellwig
2017-08-25 16:28                       ` Theodore Ts'o
2017-08-25 23:33                       ` Dave Chinner
2017-08-28  7:38                         ` Christoph Hellwig
2017-08-28 10:10                           ` Dave Chinner
2017-08-29 15:49                             ` Jan Kara
2017-08-29 22:57                               ` Dave Chinner
2017-08-30 10:00                                 ` Jan Kara
2017-08-30 12:34                                   ` Christoph Hellwig
2017-08-30 15:00                                     ` Theodore Ts'o
2017-08-30 15:30                                       ` Lukas Czerner
2017-08-30 15:29                                     ` Jan Kara
2017-08-30 16:05                                   ` Jan Kara

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=20170824182057.amdirlrbugezrahy@thunk.org \
    --to=tytso@mit.edu \
    --cc=hch@infradead.org \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.