Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [CALL FOR TESTING] Make Ext3 fsck way faster [2.6.24-rc6 -mm patch] | Date | Thu, 24 Jan 2008 11:04:53 -0800 |
| |
On Sunday 20 January 2008 18:51, Theodore Tso wrote: > 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.
Hi Ted,
OK I think you are right, because this is a nice step towards developing an on-disk extent format for Ext4 that avoids committing design mistakes to permanent storage. The benefit can be proven using a pure cache, in order to justify the considerable work necessary to make it persistent.
Chris and Jens have an effort going to implement a physical disk extent cache for loop.c. It is actually the same problem, and I smell a library here.
Issue: how do you propose to make this cache evictable?
Regards,
Daniel
| |