On Fri, 24 Aug 2007, Jon Smirl wrote: > On 8/24/07, Nicolas Pitre <nico@xxxxxxx> wrote: > > Try running "git repack -a" directly on the NSLU2. You should have the > > same performance problems as with a clone. > > This is true, it would take over 24hrs to finish. > > Is their a reason why initial clone hasn't been special cased? Why > can't initial clone just blast over the pack file already sitting on > the disk? What is the gain? You'll get back to the same performance problem eventually with some fetch operation, unless you intend to serve clients with the whole pack everytime just like the http protocol does. Also you don't want people cloning from you getting stuff that sits in your reflog. The native protocol makes sure that only the needed objects are sent over and no more. > I also wonder if a little application of some sorting to in-memory > data structures could help with the random IO patterns. I'm getting > the same data out of a stupid HTTP server and it doesn't go all IO > bound on me so a solution has to be possible. The http application is, indeed, stupid. It performs no reachability analysis, no repacking, no nothing except copying the bits over. And yes I did add some sorting optimizations in this round, so if you try 2.5.3-* you should have them. But there is a limit to what can be done. Point is, if you want serious Git serving, and not only _dumb_ protocols (http is one of them) then you need more RAM. The NSLU2 is cool, but maybe not appropriate for serving the Linux kernel natively with Git. Nicolas - To unsubscribe from this list: 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
