[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090326200258.GA10313@srcf.ucam.org>
Date: Thu, 26 Mar 2009 20:02:58 +0000
From: Matthew Garrett <mjg@...hat.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Theodore Tso <tytso@....edu>, Ingo Molnar <mingo@...e.hu>,
Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Nick Piggin <npiggin@...e.de>,
Jens Axboe <jens.axboe@...cle.com>,
David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Roland McGrath <roland@...hat.com>
Subject: Re: ext3 IO latency measurements (was: Linux 2.6.29)
On Thu, Mar 26, 2009 at 06:59:00PM +0000, Alan Cox wrote:
> > And what's the argument for not doing it in the kernel?
> >
> > The fact is, "atime" by default is just wrong.
>
> It probably was a wrong default - twenty years ago. Actually it may well
> have been a wrong default in Unix v6 8)
>
> However
> - atime behaviour is SuS required
SuS says "An implementation may update fields that are marked for update
immediately, or it may update such fields periodically. At an update
point in time, any marked fields shall be set to the current time and
the update marks shall be cleared" but doesn't appear to specify any
kind of time limit. A conforming implementation could wait a century
before performing the update. So while relatime doesn't conform, the
practical difference is meaningless. You can't depend on atime being
updated in a timely manner.
--
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists