there are performance penalties in some cases when you use directory hashing. I
did some tests last year of lots of small files in a directory tree (X/X/X/XXX
of 1k files) and I found that turning on directory hashing actually slowed down
the creation of this tree from a tarball significantly (I also found that in
this case the ext2 allocation strategy was significantly better then the ext3
one), so test on your system.
David Lang
On Tue, 20 Jun 2006, Linus Torvalds wrote:
Date: Tue, 20 Jun 2006 20:54:01 -0700 (PDT)
From: Linus Torvalds <torvalds@xxxxxxxx>
To: Martin Langhoff <martin.langhoff@xxxxxxxxx>
Cc: Nicolas Pitre <nico@xxxxxxx>, Jon Smirl <jonsmirl@xxxxxxxxx>,
git <git@xxxxxxxxxxxxxxx>
Subject: Re: packs and trees
On Wed, 21 Jun 2006, Martin Langhoff wrote:
If you are asking about the ext3 performance problems, I think Linus
discussed that a while ago, why unpacked repos are slow (in addition
to huge), and there were some suggestions of using hashed directory
indexes.
Yes. I think most distros still default to nonhashed directories, but for
any large-directory case you really want to turn on hashing.
I forget the exact details, it's somethng like
tune2fs -O dir_index
or something to turn it on (if I remember correctly, that will only affect
any directories then created after that, but you can effect that by just
doing a "git repack -a -d" which will remove all old object directories,
and now subsequent directories will be done with indexing on).
Personally, I just ended up using packs extensively, so I think I'm still
running without indexing on all my machines ;)
Linus
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html