[lkml]   [2007]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/23] per device dirty throttling -v8
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-05 17:05    [W:0.021 / U:40.552 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site