On Thu, Jan 17, 2008 at 08:27:08PM -0800, Linus Torvalds wrote: > > > On Thu, 17 Jan 2008, Shawn O. Pearce wrote: > > > > fast-import was relying on the fact that on most systems mmap() and > > write() are synchronized by the filesystem's buffer cache. We were > > relying on the ability to mmap() 20 bytes beyond the current end > > of the file, then later fill in those bytes with a future write() > > call, then read them through the previously obtained mmap() address. > > > > This isn't always true with some implementations of NFS, but it is > > especially not true with our NO_MMAP=YesPlease build time option used > > on some platforms. > > In fact, even with mmap(), it's not guaranteed. There are really crappy > mmap implementations out there, partly due to bad CPU design (virtual CPU > caches without coherency), but more often due to total crap OS. > > (Yeah, Linux did count in that area at some point. Long ago. Early 90's. > Maybe) > > I think HP-UX used to have non-coherent mmap for the longest time, due to > carrying around some totally crap memory management based on some ancient > BSD version that everybody else (including the BSD's) had long since > jettisoned. > > That said, I suspect any unix you can run today (without calling it a > retro setup) probably has coherent-enough mmap. The possible virtual cache > coherency issue is unlikely to be able to trigger this (and not relevant > on any sane hardware anyway). > > Linus I've just checked the Mac OS X build and it looks like there is a mmap and git is indeed using it, so this is obviously an example of a "really crappy" mmap implementation. This adds more ammunition to the fight against the whole Mac OS X is powered/built/based on UNIX myth. Charles. - 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
