Return-Path: <tytso@MIT.EDU>
Received: from po14.mit.edu ([unix socket])
	by po14.mit.edu (Cyrus v2.1.5) with LMTP; Thu, 10 Jul 2008 13:21:50 -0400
X-Sieve: CMU Sieve 2.2
Received: from fort-point-station.mit.edu by po14.mit.edu (8.13.6/4.7) id m6AHLn7K021973; Thu, 10 Jul 2008 13:21:50 -0400 (EDT)
Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220])
	by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m6AHLdov014517
	for <tytso@mit.edu>; Thu, 10 Jul 2008 13:21:39 -0400 (EDT)
Received: from thunker.thunk.org (www.church-of-our-saviour.ORG [69.25.196.31])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mit.edu (Spam Firewall) with ESMTP id 7D1A4A12FF4
	for <tytso@mit.edu>; Thu, 10 Jul 2008 13:21:27 -0400 (EDT)
Received: from root (helo=closure.thunk.org)
	by thunker.thunk.org with local-esmtp   (Exim 4.50 #1 (Debian))
	id 1KGzpV-0004mu-Vu; Thu, 10 Jul 2008 13:21:18 -0400
Received: from tytso by closure.thunk.org with local (Exim 4.69)
	(envelope-from <tytso@mit.edu>)
	id 1KGzpV-0000r0-D6; Thu, 10 Jul 2008 13:21:17 -0400
Date: Thu, 10 Jul 2008 13:21:17 -0400
From: Theodore Tso <tytso@MIT.EDU>
To: Eric Sandeen <sandeen@redhat.com>
Cc: rwheeler@redhat.com, linux-ext4-owner@vger.kernel.org
Subject: Re: suspiciously good fsck times?
Message-ID: <20080710172117.GE10402@mit.edu>
References: <4876025A.80909@gmail.com> <20080710151822.GA25939@mit.edu> <48762F9F.5070308@redhat.com> <48763564.2090505@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48763564.2090505@redhat.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@mit.edu
X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42

On Thu, Jul 10, 2008 at 11:14:28AM -0500, Eric Sandeen wrote:
> Val & I talked about this a little, and came to the conclusion that
> directory fragmentation might be a pretty big part of it.

Hmm, could be.  Let's see.  Ric said 46.5 million files, I don't know
how big the filenames were, but let's assume a directory entry size of
32, so that means if we assume perfect packing, 128 directory entries
per 4k block.  Let's use 100 directory entries/blok just to make the
math easyer, so that's 465,000 blocks.  If we assume a 10ms seek time,
and that the blocks are totally scattered, that's 4650 seconds, or
1.29 hours. So that's roughly within the ballpark that Ric measured.

     	       	      	      	     	 	  - Ted