linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH,RFC] ext4: add lazytime mount option
Date: Thu, 13 Nov 2014 11:35:11 -0500	[thread overview]
Message-ID: <20141113163511.GA15585@thunk.org> (raw)
In-Reply-To: <20141113064150.GI28565@dastard>

On Thu, Nov 13, 2014 at 05:41:50PM +1100, Dave Chinner wrote:
> 
> I think this needs to a VFS level inode timestamp update option.
> The games ext4 is playing with reference counts inside .drop_inode are
> pretty nasty and could be avoided if this is implemented at the VFs
> level..

I'm happy to implement this at the VFS level, assuming that there are
no objections from other file system developers.  I do need to note
that one potential downside of this feature is that if an inode stays
in the inode cache for potentially a long, long time, and the file is
a preallocated file which is updated using random DIO or AIO writes
(for example, enterprise database files on a long-running server), and
the system crashes, the mtime in memory could potentially out of synch
for days, weeks, months, etc.  I'm personally not bothered by this,
but I could imagine that some other folks might.

One other thing we could do at the VFS layer is to change the default
from relatime (which is not POSIX compliant) to enabling atime update
plus lazytime enabled (which is POSIX compliant).  Would there be
consensus in making such a change in the default?

> I think that the "lazy time update" status should really be tracked
> in the inode->i_state field. Something like lazytime updates do not
> call ->update_inode, nor do they mark the inode dirty, but they do
> update the inode->i_[acm]time fields and set a TIMEDIRTY state flag.

It looks like the only file systems that have an update_inode today is
btrfs and xfs, and it looks like this change should be fine for both
of them, so sure, that sounds workable.

						- Ted

  parent reply	other threads:[~2014-11-13 16:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12  4:07 [PATCH,RFC] ext4: add lazytime mount option Theodore Ts'o
2014-11-12 13:47 ` Dmitry Monakhov
2014-11-13 16:07   ` Theodore Ts'o
2014-11-14 11:34     ` Dmitry Monakhov
2014-11-14 11:35     ` Dmitry Monakhov
2014-11-13  6:41 ` Dave Chinner
2014-11-13  8:44   ` Boaz Harrosh
2014-11-13 16:35   ` Theodore Ts'o [this message]
2014-11-13 20:48     ` Dave Chinner
2014-11-13 21:34       ` Theodore Ts'o
2014-11-13 22:49         ` Dave Chinner

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=20141113163511.GA15585@thunk.org \
    --to=tytso@mit.edu \
    --cc=david@fromorbit.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@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 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).