From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S261483AbTCJVTY>; Mon, 10 Mar 2003 16:19:24 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S261486AbTCJVTX>; Mon, 10 Mar 2003 16:19:23 -0500
Received: from mx12.arcor-online.net ([151.189.8.88]:3039 "EHLO
	mx12.arcor-online.net") by vger.kernel.org with ESMTP
	id <S261483AbTCJVTN>; Mon, 10 Mar 2003 16:19:13 -0500
Content-Type: text/plain; charset=US-ASCII
From: Daniel Phillips <phillips@arcor.de>
To: John Bradford <john@grabjohn.com>
Subject: Re: [RFC] Improved inode number allocation for HTree
Date: Mon, 10 Mar 2003 22:33:57 +0100
X-Mailer: KMail [version 1.3.2]
Cc: ext2-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
       tytso@mit.edu, adilger@clusterfs.com, chrisl@vmware.com,
       bzzz@tmi.comex.ru
References: <200303102104.h2AL43iZ000875@81-2-122-30.bradfords.org.uk>
In-Reply-To: <200303102104.h2AL43iZ000875@81-2-122-30.bradfords.org.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Message-Id: <20030310212953.57F2310435B@mx12.arcor-online.net>
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

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