Yes, that number is very close to the first one you reported (1,004,772,198 - 1,004,771,977 = 221 bytes, probably the number of bytes needed to preparse the archive header).  There is nothing that can be done on this end about this, short of rewriting the way CVS allocates and uses memory when parsing a file, or possibly adding binary diff code to the CVS server to avoid creating such large archives in the first place (upping your server memory or refraining from checking in such large binary files might be a solution you could implement without touching the CVS internals).  We would love to see a patch!

I assume you have previously committed multiple revisions of the failing file successfully?  How big is the failing archive file (,v) in the repository?  CVS has a bad habit of loading an entire archive into memory for processing.  Even if you have committed a single 1GB revision on your server in the past, your failing file may be over 2GB or whatever your current process memory limit is. 

We have some code that already tries to use mmap for reads, in the hopes that the file system can handle some of the work for us, but it is not used for writes.  Can you check out revision 1.1 of this archive successfully?  How about the tip of a branch from this archive?  (The contrib/validate_repo script distributed with CVS 1.12.x may be useful for verifying this archive.)

If you don't appear to be having problems with the intensive read operations on this file, then mmap is working as designed for reads.  In the past, providing portable code for writable mmaps has proved troublesome, but perhaps it is worth the effort.