From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Charles Bailey <charles@hashpling.org>,
"Shawn O. Pearce" <spearce@spearce.org>,
git@vger.kernel.org, Johannes Sixt <j.sixt@viscovery.net>
Subject: Re: [PATCH] Fix random fast-import errors when compiled with NO_MMAP
Date: Fri, 18 Jan 2008 19:25:03 -0800 [thread overview]
Message-ID: <7vwsq6a44w.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LFD.1.00.0801180842350.2957@woody.linux-foundation.org> (Linus Torvalds's message of "Fri, 18 Jan 2008 09:08:23 -0800 (PST)")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Btw, even with Shawn's patch, I wonder if the index_data usage is correct.
Hmph.
gfi uses data in a "pack" in two quite different ways.
A new object is written to an unfinalized pack. Such a pack
already has "struct packed_git" allocated for it and a pointer
to it is held in pack_data. As far as the core part of git
(that is, sha1_file.c) is concerned, however, this pack does not
even exist. It is still not part of packed_git list in
sha1_file.c, and read_sha1_file() will not see objects in it, as
no idx into the packfile exists yet. gfi has a table of objects
in this pack and uses gfi_unpack_entry() function to retrieve
data from it.
A packfile is finalized in end_packfile(). The pack header and
footer is recomputed, an idx file is written, and the pack is
finally registered. Before that time p->index_data is not even
used for that pack (it is initialized with NULL).
So I do not think "index_data usage" can be incorrect, as there
won't be any index_data usage with unfinalized pack, and the
core part of git would not even have any mmap(2) (nor open fd)
into its idx file before it is finalized.
By the way, I was quite puzzled how the gfi_unpack_entry()
function manages to work correctly when it has to read an object
it deltified based on another object it wrote into the same
unfinalized pack earlier. It knows where in the unfinalized
pack it wrote the object, so it can find from its own "struct
object_entry" the offset for the object, and calls
unpack_entry() defined in the core to do the rest.
However, most of the core does not really know about the other
objects in this half-built pack. If the object is a delta,
unpack_delta_entry() needs to find the delta base. And it needs
to do that without having the idx.
The trick (the code really needs a bit more documentation) is
that gfi never writes anything but OFS_DELTA. So the core, even
though it does not have the corresponding idx file, does not
have to look up the object (in fact it does not even know what
object to look up for the base, it only knows the offset).
next prev parent reply other threads:[~2008-01-19 3:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-15 23:50 Be more careful about updating refs Linus Torvalds
2008-01-16 0:02 ` Linus Torvalds
2008-01-16 19:52 ` Junio C Hamano
2008-01-17 9:15 ` Charles Bailey
2008-01-17 10:52 ` Johannes Sixt
2008-01-17 11:01 ` Charles Bailey
2008-01-17 12:41 ` Johannes Sixt
2008-01-17 12:58 ` Johannes Schindelin
2008-01-17 13:07 ` Charles Bailey
2008-01-18 1:43 ` Junio C Hamano
2008-01-18 2:01 ` Junio C Hamano
2008-01-18 2:13 ` Shawn O. Pearce
2008-01-18 2:25 ` Junio C Hamano
2008-01-18 2:33 ` Shawn O. Pearce
2008-01-18 2:58 ` Shawn O. Pearce
2008-01-18 3:18 ` Shawn O. Pearce
2008-01-18 3:22 ` Shawn O. Pearce
[not found] ` <20080118035700.GA3458@spearce.org>
2008-01-18 4:27 ` [PATCH] Fix random fast-import errors when compiled with NO_MMAP Linus Torvalds
2008-01-18 8:42 ` Charles Bailey
2008-01-18 17:08 ` Linus Torvalds
2008-01-19 3:25 ` Junio C Hamano [this message]
2008-01-19 3:55 ` Linus Torvalds
2008-01-21 3:57 ` Shawn O. Pearce
2008-01-18 6:10 ` Junio C Hamano
2008-01-21 4:10 ` Shawn O. Pearce
2008-01-18 7:53 ` Johannes Sixt
2008-01-18 9:26 ` Charles Bailey
2008-01-18 9:36 ` Junio C Hamano
2008-01-18 9:45 ` Charles Bailey
2008-01-18 10:57 ` Junio C Hamano
2008-01-18 2:30 ` Be more careful about updating refs Shawn O. Pearce
2008-01-17 10:56 ` Charles Bailey
2008-01-16 0:29 ` Junio C Hamano
2008-01-16 0:42 ` Linus Torvalds
2008-01-16 1:11 ` Junio C Hamano
2008-01-23 22:53 ` Sam Vilain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vwsq6a44w.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=charles@hashpling.org \
--cc=git@vger.kernel.org \
--cc=j.sixt@viscovery.net \
--cc=spearce@spearce.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).