On Wed, 2006-04-19 at 07:59 -0700, Linus Torvalds wrote: > Well, you've probably got two issues: > > - it looks like you aren't packing your archives (which explains why the > disk accesses are horrid, which in turn explains the "D" part). Hm, good point. They're fairly new trees -- I had foolishly assumed that they would at least start off packed. That isn't the case though -- perhaps it should be? Did the original clone receive a pack on the wire and then _split_ it? If the tools would automatically pack when the number of unpacked objects reaches a threshold, that would be useful. Since this repo is only available through git:// and git+ssh:// URLs, I can safely use git-repack's '-a -d' options, right? I'll do 'git-repack -l' nightly and 'git-repack -a -d -l' weekly -- does that seem sane? > For a git server, you _really_ want all trees to be mostly packed, or > you want absolutely tons of memory (and 256kB is definitely not "tons" > as far as git is concerned). > > Well, the way things work under UNIX, you normally don't notice that the > other end isn't interested until you try to write, and you get a "nobody > is listening". And sadly, the packing stuff does most (not all) of the > heavy lifting before it can even start to write things out. Well, it does that with SIGALRM happening periodically, theoretically for the purpose of providing progress output. Perhaps we could do a getpeername() or something else to check on the output fd each time? -- dwmw2 - : 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