Date:	Mon, 08 Jan 2007 08:43:01 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Theodore Tso <tytso@....edu>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Andrew Morton <akpm@...l.org>, Willy Tarreau <w@....eu>,
	Linus Torvalds <torvalds@...l.org>,
	"H. Peter Anvin" <hpa@...or.com>, git@...r.kernel.org,
	nigel@...el.suspend2.net, "J.H." <warthog9@...nel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	webmaster@...nel.org,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: How git affects kernel.org performance

Theodore Tso wrote:
> The fastest and probably most important thing to add is some readahead
> smarts to directories --- both to the htree and non-htree cases.  If
> you're using some kind of b-tree structure, such as XFS does for
> directories, preallocation doesn't help you much.  Delayed allocation
> can save you if your delayed allocator knows how to structure disk
> blocks so that a btree-traversal is efficient, but I'm guessing the
> biggest reason why we are losing is because we don't have sufficient
> readahead.  This also has the advantage that it will help without
> needing to doing a backup/restore to improve layout.


Something I just thought of:  ATA and SCSI hard disks do their own 
read-ahead.  Seeking all over the place to pick up bits of directory 
will hurt even more with the disk reading and throwing away data (albeit 
in its internal elevator and cache).

	Jeff


-
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

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux