lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bqdffnn5.fsf@graviton.dyn.troilus.org>
Date:	Fri, 10 Aug 2007 10:51:58 -0400
From:	Michael Poole <mdpoole@...ilus.org>
To:	Vlad <vladc6@...oo.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Noatime vs relatime

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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ