From owner-freebsd-fs  Tue Nov 25 10:31:22 1997
Return-Path: <owner-freebsd-fs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA05582
          for fs-outgoing; Tue, 25 Nov 1997 10:31:22 -0800 (PST)
          (envelope-from owner-freebsd-fs)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA05565
          for <fs@FreeBSD.ORG>; Tue, 25 Nov 1997 10:31:17 -0800 (PST)
          (envelope-from bde@zeta.org.au)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id FAA15404; Wed, 26 Nov 1997 05:26:57 +1100
Date: Wed, 26 Nov 1997 05:26:57 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199711251826.FAA15404@godzilla.zeta.org.au>
To: bde@zeta.org.au, tlambert@primenet.com
Subject: Re: ufs slowness
Cc: fs@FreeBSD.ORG
Sender: owner-freebsd-fs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>> After copying from ext2fs to ffs using two tars in a pipe, ffs is exactly
>> as slow as before, although I've disturbed the ffs partition a little
>> by building a world in it (it grew from 53% full to 66% full).
>
>How about copying back to ext2fs?  Then at least the same algorithm
>will have populated both.

See later mail.  It's slower, but I think that is because the FreeBSD
ext2fs is worse that the Linux one :-).

>I think "optimal" might be "in such a way that a file may not displace
>a directory from cache".
>
>This would imply:
>
>1)	Breadth first
>2)	Create all files before subdirectories for any directory
>
>Of course, I could be wrong.  If it's depth first, with no way to
>adjust it, you'd want the directories first.

It's othing to do with that - see later mail.

ffs wants to seek a lot to switch cylinder groups (for almost every new
directory?), but I think the main problem is that it wants to seek lot
to handle fragments.  I'm now making space to repartition.  I'll try a
4K/4K ffs to match the ext2fs block size exactly.

Another thing: it didn't help to move all the files into one big directory
(with ~2500 files and 38MB data).  This was 20% slower, presumably due
to the directory being too big to cache properly.

Bruce