On Wed, Aug 08, 2007 at 05:54:57PM -0700, Martin Bligh wrote:
quoted text
> Andrew Morton wrote:
> >On Wed, 08 Aug 2007 14:10:15 -0700
> >"Martin J. Bligh" <mbligh@mbligh.org> 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.

-VAL
-
unsubscribe notice
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/