To: Vlad <vladc6@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Noatime vs relatime
References: <233939.75965.qm@web54403.mail.yahoo.com>
From: Michael Poole <mdpoole@troilus.org>
Date: Fri, 10 Aug 2007 10:51:58 -0400
In-Reply-To: <233939.75965.qm@web54403.mail.yahoo.com> (Vlad's message of "Fri\, 10 Aug 2007 07\:26\:46 -0700 \(PDT\)")
Message-ID: <87bqdffnn5.fsf@graviton.dyn.troilus.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1680
Lines: 37

Vlad writes:

> Relatime seems to be wasteful of both IO resources _and_ CPU cycles.
> Instead of performing a single IO operation (as atime does), relatime
> performs at least three IO operations and three CPU-dependent
> operations:
>
> 1) a read IO operation to find out the old atime
> 2) a read IO operation to find out the old ctime
> 3) a read IO operation to find out the old mtime
> 4) Comparison of "old atime is <= than mtime/ctime"
> 5) Find out current time
> 6) Comparison of "current time minus old atime is > X"
>
> People are going to wonder why all of the sudden everything is running
> so slow due to atimes being updated after a long break.

Filesystems deal with block devices, which have fairly large (at least
512-byte) read and write granularity.  Sane filesystems have atime,
ctime and mtime all in the same block, so one read gets all three.
The file's metadata would be in the cache while it's open anyway.

CPU operations are many orders of magnitude faster than block I/O, so
if steps 4-6 eliminate even a fraction of a percent of atime
writebacks, relatime is a net benefit.  In practice, most files are
read many more times than they are written, and most of those are
eliminated even with step #6.  Academic journals abound with
storage-related studies of read versus write patterns (often including
temporal locality of reference) for various kinds of files; I refer
you to those for details.

Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/