Junio C Hamano <gitster@xxxxxxxxx> wrote:
> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
>
> > We have a file position we saw once before as the start of a delta.
> > We wrote it down to disk. We want to go back and open it up, as
> > we have the base decompressed and in memory and need to compute
> > the SHA-1 of the object that resides at this offset.
> >
> > And *wham* we get an EOF. Where there should be data. Where we
> > know there is data.
>
> We have written that earlier in the same process? Are we playing games
> with mixed mmap() and pread()? Is fsync() or msync() or unmap/remap
> needed?
Yes, we wrote the very same file earlier in the process.
index-pack _used_ to use a mixed write/mmap game. Today it uses
write, followed by later pread. No mmap. We had major performance
issues on Mac OS X with mmap, not to mention the coherency issues
that can arise from using it. So index-pack is mmap free[*1*].
> > Actually, I think the last time someone reported something like this
> > in Git it turned out to be an NFS kernel bug. I didn't quote it
> > in my reply to him, but I think he did say this was a linux client,
> > linux server.
>
> This is getting into the area Linus would immediately know the answer to,
> but he is away for this week.
Yea, I was expecting a reply from him, but that explains it.
*1* There is usage of mmap in index-pack, but only to access
_existing_ objects and packs from the object store.
--
Shawn.
--
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
