linux-ext4 - Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080121025117.GB8105@mit.edu>
Date:	Sun, 20 Jan 2008 21:51:17 -0500
From:	Theodore Tso <tytso@....EDU>
To:	Daniel Phillips <phillips@...nq.net>
Cc:	Abhishek Rai <abhishekrai@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, rohitseth@...gle.com,
	linux-ext4@...r.kernel.org
Subject: Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm
	patch]

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-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html