On Mon 10 Mar 03 22:04, John Bradford wrote:
> > Though the journal only becomes involved when blocks are modified,
> > unfortunately, because of atime updates, this includes all directory
> > operations. We could suggest to users that they should disable
> > atime updating if they care about performance, but we ought to be
> > able to do better than that.
>
> On a separate note, since atime updates are not usually very important
> anyway, why not have an option to cache atime updates for a long time,
> or until either a write occurs anyway. Holding a large number of
> atime updates in a write cache is generally not going to be a major
> issue - the worst case if a partition isn't cleanly unmounted is that
> some atimes will be wrong.
It sounds practical. Why stop there? Since Ted is seriously considering
making a batch of incompatible extensions to the on-disk format anyway, how
about adding an atime table to each block group, four bytes per inode. Even
without lazy updating, it would cut down the dirty blocks generated by r/o
operations a lot. If actual atime is the latest of the atime table value and
the inode atime value[1], then inode write operations won't generate extra
traffic. You will only get new traffic when somebody wants the real atime.
I'd put this under the category of "things to add to Ted's long list of fun
new ideas for Ext3/4".
[1] How to handle wrapping is left as an exercise for the interested reader.
Regards,
Daniel
-
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/
This archive was generated by hypermail 2b29 : Sat Mar 15 2003 - 22:00:23 EST