git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git-{repack,pack-objects} accept --{pack,blob}-limit to control pack size

From
Shawn O. Pearce <spearce@spearce.org>
Date
Apr 5, 2007, 15:53 UTC
Message-ID
<20070405155306.GI5436@spearce.org>
In-Reply-To
<Pine.LNX.4.64.0704050831520.6730@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 11 quoted lines
> 
> On Thu, 5 Apr 2007, Shawn O. Pearce wrote:
> > 
> > For glibc we do try to set _FILE_OFFSET_BITS to 64
> 
> I repeat: that's _broken_.
> 
> It's in no way portable. It's a glibc horror. It should not be used.
> 
> It was a quick hack, but the real way to do it is to use "loff_t" and 
> "llseek".
Sure, OK, but that libc function doesn't exist on Mac OS X:
man llseek:
  This function is Linux-specific, and should not be used in programs
  intended to be portable.
So we'd need our own horror to wrap llseek as an lseek fake-alike
anyway.  That's what that glibc horror does, and we didn't have to
write that code.  :-)
 
> But there simply isn't any way to do mmap() or pread() portably outside 
> the 32-bit area. So there are good reasons why we should just limit 
> pack-files to 32-bits on 32-bit architectures.

Not unless your off_t is 64 bits, no. If it is 64 bits then you should be able to do a pread or mmap starting past the first 2 GiB. You just might not be able to ask for a mmap that exceeds 2 GiB in size, as your size_t may not be that large. E.g., Darwin/Mac OS X. Hence the sliding window mmap.

> So I think that Dana's approach is just fundamentally correct. Yeah, we 
> should probably have a 64-bit index as a *possibility*, but it simply 
> isn't a replacement for "keep packs under 2GB in size".
I'm not disagreeing.  Some filesystems (FAT on a USB stick, Dana's
example) just don't want files larger than 2 GiB.  So keeping them
small has a number of advantages.  Plus they are easier to burn on
DVD: 2 packs per DVD.  ;-)

I was simply trying to point out that the mmap code isn't broken if the off_t is able to handle a file of that size; and if it can't then other things are broken, like a simple lseek.

-- 
Shawn.
Previous: Linus TorvaldsNext: Linus Torvalds
Message 9 of 12 in “git-{repack,pack-objects} accept --{pack,blob}-limit to control pack size”
  1. git-{repack,pack-objects} accept --{pack,blob}-limit to control pack sizeDana How, Apr 4, 2007
  2. Nicolas PitreApr 4, 2007
  3. Dana HowApr 4, 2007
  4. Nicolas PitreApr 5, 2007
  5. Shawn O. PearceApr 5, 2007
  6. Nicolas PitreApr 5, 2007
  7. Shawn O. PearceApr 5, 2007
  8. Linus TorvaldsApr 5, 2007
  9. Shawn O. PearceApr 5, 2007
  10. Linus TorvaldsApr 5, 2007
  11. Shawn O. PearceApr 5, 2007
  12. Florian WeimerApr 5, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.