[lkml]   [2007]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/23] per device dirty throttling -v8
    On Wed, Aug 08, 2007 at 05:54:57PM -0700, Martin Bligh wrote:
    > Andrew Morton wrote:
    > >On Wed, 08 Aug 2007 14:10:15 -0700
    > >"Martin J. Bligh" <> wrote:
    > >
    > >>Why isn't this easily fixable by just adding an additional dirty
    > >>flag that says atime has changed? Then we only cause a write
    > >>when we remove the inode from the inode cache, if only atime
    > >>is updated.
    > >
    > >I think that could be made to work, and it would fix the performance
    > >issue.
    > >
    > >It is a behaviour change. At present ext3 (for example) commits everything
    > >every five seconds. After a change like this, a crash+recovery could cause
    > >a file's atime to go backwards by an arbitrarily large time interval - it
    > >could easily be months.
    > A second pdflush / workqueue at a slower rate would alleviate that.

    This becomes delayed atime writes. I'm not sure that it's better to
    batch up the writes and do them all in one big seeky go, or to trickle
    them out as they are done. Best of all is not to do them at all.

    Note when talking about saving up atime updates to write out that the
    final write is going to be sloooooow. Inodes are typically 128 bytes,
    and you may have to do a seek between every one. Currents disks can
    do on the order of 100 seeks a second. So do a find on 1000 files and
    you've just created 10 seconds of I/O hanging out in memory.

    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-12 01:17    [W:0.021 / U:0.900 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site