On Mon, 17 Jul 2006, Geert Bosch wrote: > > Or we can avoid doing an mmap of the entire pack file, and instead > try to be somewhat smart on limiting the size of the mmap's. > This might be sufficient to help Windows and also solve the > issue of finding contiguous address space for large packs on > 32-bit systems. Well, the thing is, you really _do_ want to mmap as much as possible of the pack-file as possible, if mmap() works. So even with large pack-files, you do want to mmap a huge chunk at a time, even if it turns out that you only need a very small part of it. For example, the commit data is at the very beginning of the pack-file, so if you only look at the history, you only look at a very small part of the pack-file, but you should not have to know how much you'll need ahead of time, so you'd still want the pack-file operations to act in a way that is efficient for the general case (which is to mmap as much as possible). So yes, we'll need to have some chunking layer at some point (when people have gigabyte pack-files) but I think that's a totally separate issue from the fact that we _do_ actually want mmap() (the _real_ kind of mmap) for pack-files. 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