Re: selectively disabling atime updates?

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Jun 11, 2012 at 03:45:13PM +0200, Edgar Fu? wrote:
> > This makes me think that /etc/daily should take similar steps,
> > whatever they turn out to be.
>
> Yes, allthough my RAIDframe performance test results show that the effect
> decreases with larger block sizes.

You know, it strikes me that access-time updates probably go through the
journal, since they touch the inode.  And *that* makes me think that:

        * Perhaps the access time should not be in the inode, or should
          be hoisted out of the same disk block as critical inode fields
          so it can be written without risk of damage to them.

        * Otherwise, some of these not-actually-critical transactions should
          be buffered somehow before being written to the journal so they
          can be batched more efficiently.

I suspect the cache-flushing behavior of the journaling code is effectively
destroying the read priority design of the disk sorting strategy, causing
the commit of the atime writes to stall everything and thus really wreck
performance.  I could be way off, but it's a strong hunch.  And I think I
recall seeing the XFS guys take fairly drastic measures to deal with a
similar problem some years ago as well.

Thor