From: Daniel Phillips <phillips@arcor.de>
To: John Bradford <john@grabjohn.com>
Cc: ext2-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
tytso@mit.edu, adilger@clusterfs.com, chrisl@vmware.com,
bzzz@tmi.comex.ru
Subject: Re: [RFC] Improved inode number allocation for HTree
Date: Mon, 10 Mar 2003 22:33:57 +0100 [thread overview]
Message-ID: <20030310212953.57F2310435B@mx12.arcor-online.net> (raw)
In-Reply-To: <200303102104.h2AL43iZ000875@81-2-122-30.bradfords.org.uk>
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
next prev parent reply other threads:[~2003-03-10 21:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-27 17:31 [Bug 417] New: htree much slower than regular ext3 Martin J. Bligh
2003-02-28 2:55 ` Daniel Phillips
2003-02-27 21:00 ` Andreas Dilger
2003-02-28 4:12 ` Daniel Phillips
2003-02-27 21:33 ` Martin J. Bligh
2003-03-13 21:04 ` [Ext2-devel] " Stephen C. Tweedie
2003-03-07 15:46 ` Alex Tomas
2003-03-08 17:38 ` Daniel Phillips
2003-03-07 23:27 ` Theodore Ts'o
2003-03-09 19:26 ` Alex Tomas
2003-03-09 7:08 ` Alex Tomas
2003-03-10 17:58 ` Daniel Phillips
2003-03-10 21:25 ` Theodore Ts'o
2003-03-11 21:57 ` Bill Davidsen
[not found] ` <20030307214833.00a37e35.akpm@digeo.com>
[not found] ` <20030308010424.Z1373@schatzie.adilger.int>
2003-03-09 22:54 ` [Ext2-devel] " Daniel Phillips
2003-03-08 23:19 ` Andrew Morton
2003-03-09 23:10 ` Daniel Phillips
[not found] ` <20030309184755.ACC80FCA8C@mx12.arcor-online.net>
[not found] ` <m3u1ecl5h8.fsf@lexa.home.net>
2003-03-10 20:45 ` [RFC] Improved inode number allocation for HTree Daniel Phillips
[not found] ` <3E6D1D25.5000004@namesys.com>
[not found] ` <20030311031216.8A31CEFD5F@mx12.arcor-online.net>
2003-03-11 10:45 ` Hans Reiser
2003-03-11 13:00 ` Helge Hafting
2003-03-11 13:41 ` Daniel Phillips
2003-03-11 17:16 ` Andreas Dilger
2003-03-11 19:39 ` Helge Hafting
2003-03-11 20:19 ` Daniel Phillips
2003-03-11 21:25 ` atomic kernel operations are very tricky to export to user space (was [RFC] Improved inode number allocation for HTree ) Hans Reiser
2003-03-11 23:49 ` Jamie Lokier
2003-03-10 20:48 ` [RFC] Improved inode number allocation for HTree Daniel Phillips
2003-03-10 21:04 ` John Bradford
2003-03-10 21:28 ` Andreas Schwab
2003-03-10 21:50 ` Filesystem write priorities, (Was: Re: [RFC] Improved inode number allocation for HTree) John Bradford
2003-03-14 21:55 ` [Ext2-devel] " Stephen C. Tweedie
2003-03-10 21:33 ` Daniel Phillips [this message]
2003-03-10 21:47 ` [Ext2-devel] Re: [RFC] Improved inode number allocation for HTree Bryan O'Sullivan
2003-03-10 22:02 ` Matthew Wilcox
2003-03-11 8:47 ` Jakob Oestergaard
2003-03-11 11:27 ` John Bradford
2003-03-14 21:57 ` Stephen C. Tweedie
2003-03-15 8:39 ` jw schultz
[not found] <20030311194014$426e@gated-at.bofh.it>
[not found] ` <20030311194014$1a3c@gated-at.bofh.it>
[not found] ` <20030311194014$78c3@gated-at.bofh.it>
[not found] ` <20030311194014$5811@gated-at.bofh.it>
[not found] ` <20030311194014$49a6@gated-at.bofh.it>
2003-03-11 20:14 ` Pascal Schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030310212953.57F2310435B@mx12.arcor-online.net \
--to=phillips@arcor.de \
--cc=adilger@clusterfs.com \
--cc=bzzz@tmi.comex.ru \
--cc=chrisl@vmware.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=john@grabjohn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).