mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Daniel Phillips <phillips@arcor.de>
Cc: adilger@clusterfs.com, tytso@mit.edu, bzzz@tmi.comex.ru,
	mbligh@aracnet.com, linux-kernel@vger.kernel.org,
	ext2-devel@lists.sourceforge.net
Subject: Re: [Ext2-devel] Re: [Bug 417] New: htree much slower than regular ext3
Date: Sat, 8 Mar 2003 15:19:56 -0800	[thread overview]
Message-ID: <20030308151956.5ed1c05a.akpm@digeo.com> (raw)
In-Reply-To: <20030308224956.E1E4FF1859@mx12.arcor-online.net>

Daniel Phillips <phillips@arcor.de> wrote:
>
> Yes, I think that's exactly what's happening.  There are some questions 
> remaining, such as why doesn't it happen to akpm.

Oh but it does.  The 30,000 mkdirs test takes 76 seconds on 1k blocks, 16
seconds on 4k blocks.

With 1k blocks, the journal is 1/4 the size, and there are 4x as many
blockgroups.

So not only does the fs have to checkpoint 4x as often, it has to seek all
over the disk to do it.

If you create a 1k blocksize fs with a 100MB journal, the test takes just
nine seconds.

But note that after these nine seconds, we were left with 50MB of dirty
buffercache.  When pdflush later comes along to write that out it takes >30
seconds, because of the additional fragmentation from the tiny blockgroups.
So all we've done is to pipeline the pain.

I suspect the Orlov allocator isn't doing the right thing here - a full
dumpe2fs of the disk shows that the directories are all over the place. 
Nodoby has really looked at fine-tuning Orlov.

btw, an `rm -rf' of the dir which holds 30,000 dirs takes 50 seconds system
time on a 2.7GHz CPU.  What's up with that?

c01945bc str2hashbuf                                9790  61.1875
c0187064 ext3_htree_store_dirent                   10472  28.7692
c0154920 __getblk                                  11319 202.1250
c018d11c dx_probe                                  15934  24.2896
c018d4d0 ext3_htree_fill_tree                      15984  33.8644
c0188d3c ext3_get_branch                           18238  81.4196
c0136388 find_get_page                             18617 202.3587
c015477c bh_lru_install                            20493  94.8750
c0194290 TEA_transform                             21463 173.0887
c01536b0 __find_get_block_slow                     24069  62.6797
c0154620 __brelse                                  36139 752.8958
c01893dc ext3_get_block_handle                     43815  49.7898
c0154854 __find_get_block                          71292 349.4706


  reply	other threads:[~2003-03-08 23:09 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-27 17:31 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 [this message]
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=20030308151956.5ed1c05a.akpm@digeo.com \
    --to=akpm@digeo.com \
    --cc=adilger@clusterfs.com \
    --cc=bzzz@tmi.comex.ru \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=phillips@arcor.de \
    --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

all inboxes | Powered by JetHome®