public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Lachlan McIlroy <lachlan@sgi.com>
Cc: David Chinner <dgc@sgi.com>,
	Utako Kusaka <u-kusaka@wm.jp.nec.com>,
	xfs@oss.sgi.com
Subject: Re: [PATCH] flush inode when changing atime.
Date: Thu, 18 Oct 2007 14:17:36 +1000	[thread overview]
Message-ID: <20071018041736.GA66820511@sgi.com> (raw)
In-Reply-To: <4716D891.1060108@sgi.com>

On Thu, Oct 18, 2007 at 01:52:49PM +1000, Lachlan McIlroy wrote:
> David Chinner wrote:
> >On Wed, Oct 17, 2007 at 01:56:00PM +0900, Utako Kusaka wrote:
> >>Hi,
> >>
> >>The atime is changed for reading but it returns to a previous value
> >>after unmount. i_update_core is still off after reading a file using
> >>read(), readdir() and readlink(). So an inode isn't flushed to disk.
> >
> >I think this was done by design - Christoph? I can't remember exactly
> >as it was more than two years ago this change was made. It is effectively
> >equivalent to using the relatime mount option.
> >
> >The question is whether we want to change the default behaviour or
> >whether we need to supply an "atimeisatime" mount option for those
> >that really need atime to be updated on every access.
> >
> If we change it back then will anything that scans the filesystem cause
> inodes to be dirtied and create a lot of inode flush traffic that we
> don't currently have?

Right. And given that it's taken over 2 years for anyone to notice
that atime only get updated when a file is otherwise dirtied....

> >If we are going to put these back in, then they should be
> >calls to xfs_ichgtime_fast() so that we know what the reason
> >for marking the core dirty is.
> 
> xfs_ichgtime_fast() will also dirty the linux inode so that sync
> will push out the change.

The VFS already calls filp_accessed, which marks the linux inode
dirty. We're telling sync that the inode really isn't dirty when
it tries to flush it, so it's not going to disk....

As Christoph pointed out last night to me the problem really is that
VFS atime updates don't have a callback into the filesystem(*) so if
we want to write back atime we've basically got to duplicate VFS
infrastructure. 

(*) i.e. call ->setattr to set the atime.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  reply	other threads:[~2007-10-18  4:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-17  4:56 [PATCH] flush inode when changing atime Utako Kusaka
2007-10-17  9:08 ` David Chinner
2007-10-18  3:52   ` Lachlan McIlroy
2007-10-18  4:17     ` David Chinner [this message]
2007-10-18  8:01       ` Lachlan McIlroy

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=20071018041736.GA66820511@sgi.com \
    --to=dgc@sgi.com \
    --cc=lachlan@sgi.com \
    --cc=u-kusaka@wm.jp.nec.com \
    --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