Re: pread() over NFS (again) [1.5.5.4]

From: Nicolas Pitre <nico@cam.org>
Date: Jun 30, 2008, 19:09 UTC
Message-ID: <alpine.LFD.1.10.0806301457590.19095@xanadu.home>
In-Reply-To: <20080630003203.GJ11793@spearce.org>

On Sun, 29 Jun 2008, Shawn O. Pearce wrote:

Show 16 quoted lines

> Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> > Is the file only being read, or could there be a simultaneous write to
> > the same file? I'm surmising this could be an effect resulting from
> > simultaneous cache invalidations: prior to Linux 2.6.20 or so, we
> > weren't rigorously following the VFS/VM rules for page locking, and so
> > page cache invalidation in particular could have some curious
> > side-effects.
> 
> The file was created and opened O_CREAT|O_EXCL|O_RDWR, by this
> process, written linearly using write(2), without any lseeks.
> We kept the file descriptor open and starting issuing pread(2)
> calls for earlier offsets we had alread written.  One of those
> kicks back EOF far too early (and results in this bug report).
> 
> Note the only accesses we are using is write(2) and pread(2), and
> once we start reading we don't ever go back to writing.

That's not exact. With a thin pack, we continue appending data to the file after a bunch of pread() have occurred. And only after those pread()'s do we know that we actually have a thin pack.

> The pread(2)
> calls are typically issued in ascending offsets, and we read each
> position only once.  This is to try and take advantage of any
> read-ahead the kernel may be able to do.

That's not exact. The pread() calls are done when resolving deltas, hence a base object is read and every deltas based on it are recursively resolved to find their SHA1 signature. Then another base is picked up and the same process repeated. And in practice all those delta chains are all interleaced in the pack file due to the fact that objects are stored so to optimize access to recent commits. Therefore they're more or less random.

Nicolas