Excerpts from Mitch Harder's message of 2011-08-04 14:40:20 -0400:
> On Thu, Aug 4, 2011 at 10:05 AM, Chris Mason <chris.ma...@oracle.com> wrote:
> >>
> >> Ok, so I'm going to guess that your problem is really with either file
> >> layout or just us using more metadata pages than the others.  The file
> >> layout part is easy to test, just replace your git repo with a fresh
> >> clone (or completely repack it).
> >
> > Sorry, I should have said replace your git repo with a fresh,
> > non-hardlinked clone.  git clone by default will just make hardlinks if
> > it can, so it has to be a fresh clone.
> >
> > -chris
> >
> 
> Oops, sorry, I let my responses slip off the list.
> 
> You are right about there being a potentially huge difference between
> a cloned git repo and it's parent.  I didn't realize it could make
> such a difference.
> 
> This problem now appears to have nothing to do with btrfs.  I can
> replicate the problem on an ext4 partition also if I use a copy of the
> parent git repository instead of a clone.  The problem seems to lie in
> the fragmentation of the git repository.
> 
> If I work with a clone of my linux-btrfs repository, subsequent clones
> are much faster.  Cloning my parent linux-btrfs repo takes about 90
> minutes (when I have restricted free RAM).  Cloning a clone of the
> parent drops down to less than 10 minutes.
> 
> With there being several other threads relating to btrfs 'slow downs',
> I though this issue might be related.

Great, glad to hear turned out to be filesystem agnostic.

The original git file format was basically very filesystem unfriendly
and it tends to fragment very badly. 

Linus' solution to this is the pack file format, which is space
efficient and very fast to access.  The only downside is that you need
to repack the repo from time to time or performance tends to fall off a
cliff.

There is a git-pack command and a git gc command that you can use to
restructure things, both making it smaller and much faster.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to