public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@MIT.EDU>
To: Daniel Phillips <phillips@phunq.net>
Cc: Abhishek Rai <abhishekrai@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, rohitseth@google.com,
	linux-ext4@vger.kernel.org
Subject: Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]
Date: Sun, 20 Jan 2008 21:51:17 -0500	[thread overview]
Message-ID: <20080121025117.GB8105@mit.edu> (raw)
In-Reply-To: <200801192010.20699.phillips@phunq.net>

On Sat, Jan 19, 2008 at 08:10:20PM -0800, Daniel Phillips wrote:
> 
> I can see value in preemptively loading indirect blocks into the buffer 
> cache, but is building a second-order extent tree really worth the 
> effort?  Probing the buffer cache is very fast.

It's not that much effort, and for a big database (say, like a 50GB
database file), the indirect blocks would take up 50 megabytes of
memory.  Collapsing it into an extent tree would save that memory into
a few kilobytes.  I suppose a database server would probably have
5-10GB's of memory, so the grand scheme of things it's not a vast
amount of memory, but the trick is keeping the indirect blocks pinned
so they don't get pushed out by some vast, gigunndo Java application
running in the same server as the database.  If you have the indirect
blocks encoded into the extent tree, then you don't have to worry
about that.

            	       	     	     	   - Ted

  reply	other threads:[~2008-01-21  2:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200801140839.01986.abhishekrai@google.com>
2008-01-15  0:34 ` [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch] Andrew Morton
2008-01-15 11:04   ` Andrew Morton
2008-01-15 13:15     ` Christoph Hellwig
2008-01-15 13:16       ` Christoph Hellwig
2008-01-15 15:28       ` Theodore Tso
2008-01-17 12:47         ` Abhishek Rai
2008-01-20  4:10           ` Daniel Phillips
2008-01-21  2:51             ` Theodore Tso [this message]
2008-01-24 19:04               ` Daniel Phillips
2008-01-15 15:09     ` Ric Wheeler
2008-01-16  5:08       ` Valdis.Kletnieks
2008-01-16  4:25     ` Valdis.Kletnieks
2008-01-17 11:36       ` Andreas Dilger
2008-01-20  3:55     ` Daniel Phillips
2008-01-23  9:12 Abhishek Rai
2008-01-24  7:49 ` Andrew Morton
2008-01-24 13:14   ` Abhishek Rai

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=20080121025117.GB8105@mit.edu \
    --to=tytso@mit.edu \
    --cc=abhishekrai@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillips@phunq.net \
    --cc=rohitseth@google.com \
    /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