Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757880AbYAUCwW (ORCPT ); Sun, 20 Jan 2008 21:52:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756094AbYAUCwN (ORCPT ); Sun, 20 Jan 2008 21:52:13 -0500 Received: from BISCAYNE-ONE-STATION.MIT.EDU ([18.7.7.80]:35514 "EHLO biscayne-one-station.mit.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753236AbYAUCwM (ORCPT ); Sun, 20 Jan 2008 21:52:12 -0500 Date: Sun, 20 Jan 2008 21:51:17 -0500 From: Theodore Tso To: Daniel Phillips Cc: Abhishek Rai , Christoph Hellwig , Andrew Morton , 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] Message-ID: <20080121025117.GB8105@mit.edu> Mail-Followup-To: Theodore Tso , Daniel Phillips , Abhishek Rai , Christoph Hellwig , Andrew Morton , linux-kernel@vger.kernel.org, rohitseth@google.com, linux-ext4@vger.kernel.org References: <200801140839.01986.abhishekrai@google.com> <20080115152801.GA7292@mit.edu> <200801192010.20699.phillips@phunq.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200801192010.20699.phillips@phunq.net> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-Spam-Flag: NO X-Spam-Score: 0.00 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1176 Lines: 23 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/