Re: [PATCH 00/23] per device dirty throttling -v8

[Theodore Tso <tytso@mit.edu>]

On Sun, Aug 05, 2007 at 02:26:53AM +0200, Andi Kleen wrote:
> I always thought the right solution would be to just sync atime only
> very very lazily. This means if a inode is only dirty because of an
> atime update put it on a "only write out when there is nothing to do
> or the memory is really needed" list.

As I've mentioend earlier, the memory balancing issues that arise when
we add an "atime dirty" bit scare me a little.  It can be addressed,
obviously, but at the cost of more code complexity.

An alternative is to simply have a tunable parameter, via either a
mount option or stashed in the superblock which controls atime's
granularity guarantee.  That is, only update the atime if it is older
than some set time that could be configurable as a mount option or in
the superblock.  Most of the time, an HSM system simply wants to know
if a file has been used sometime "recently", where recently might be
measured in hours or in days.

This is IMHO slightly better than relatime, since it keeps the spirit
of the atime update, while keeping the performance impact to a very
minimal (and tunable) level.

						- Ted

P.S.  Yet alternative is to specify noatime on an individual
file/directory basis.  We've had this capability for a *long* time,
and if a distro were to set noatime for all files in certain
hierarchies (i.e., /usr/include) and certain top-level directories
(since the chattr +A flag is inherited), I think folks would find that
this would reduce the I/O traffic of noatime by a huge amount.  This
also would be 100% POSIX compliant, since we are extending the
filesystem and setting certain files to use it.  But if users want to
know when was the last time they looked at a particular file in their
home directory, they would still have that facility.

-
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/