From: Daniel Phillips <phillips@arcor.de>
To: "Martin J. Bligh" <mbligh@aracnet.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: ext2-devel@lists.sourceforge.net, "Theodore Ts'o" <tytso@mit.edu>,
chrisl@vmware.com
Subject: Re: [Bug 417] New: htree much slower than regular ext3
Date: Fri, 28 Feb 2003 03:55:37 +0100 [thread overview]
Message-ID: <20030227200425.253F03FE26@mx01.nexgo.de> (raw)
In-Reply-To: <11490000.1046367063@[10.10.2.4]>
On Thursday 27 February 2003 18:31, Martin J. Bligh wrote:
> Problem Description:
> I created a directory ("test") with 32000 (ok, 31998) directories in it,
> and put a file called 'foo' in each of them (for i in `ls`; do cd $i &&
> touch bar && cd .. ; done). Then I took that ext3 partion, umounted it,
> did a 'tune2fs -O dir_index', then 'fsck -fD', and remounted. I then did a
> 'time du -hs' on the test directory, and here are the results.
>
> ext3+htree:
> bwindle@razor:/giant/inodes$ time du -hs
> 126M .
>
> real 7m21.756s
> user 0m2.021s
> sys 0m22.190s
>
> I then unmounted, tune2fs -O ^dir_index, e2fsck -fD /dev/hdb1, remounted,
> and did another du -hs on the test directory. It took 1 minute, 48
> seconds.
>
> bwindle@razor:/giant/test$ time du -hs
> 126M .
>
> real 1m48.760s
> user 0m1.986s
> sys 0m21.563s
>
>
> I thought htree was supposed to speed up access with large numbers of
> directories?
The du just does getdents and lstats in physical storage order, so there's no
possible benefit from indexing in this case, and unindexed ext3 avoids long
search times by caching the position at which it last found an entry. That
answers the question "why doesn't it speed up", however, "why did it slow way
down" is harder.
The single-file leaves of your directory tree don't carry any index (it's not
worth it with only one file) and therfore use the same code path as unindexed
ext3, so there's no culprit there. I'm looking suspiciously at
ext3_dx_readdir, which is apparently absorbing about 11 ms per returned
entry. To put this in perspective, I'm used to seeing individual directory
operation times well below 100 us, so even if each dirent cost as much as a
full lookup, you'd see less than 3 seconds overhead for your 30,000
directories.
11 ms sounds like two seeks for each returned dirent, which sounds like a bug.
Regards,
Daniel
next prev parent reply other threads:[~2003-02-27 19:54 UTC|newest]
Thread overview: 38+ 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 [this message]
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 ` [RFC] Improved inode number allocation for HTree Daniel Phillips
2003-03-10 21:47 ` [Ext2-devel] " 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
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=20030227200425.253F03FE26@mx01.nexgo.de \
--to=phillips@arcor.de \
--cc=chrisl@vmware.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--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).