Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
Duy Nguyen writes: > I get annoyed by the "ignoring unknown extension xxx" messages while > testing though (not just this extension) and I think it will be the > same for other git implementations. But perhaps other implementations > just silently drop the extension. Most of the extensions we have added > so far (except the ancient 'TREE') are optional and are probably not Most of the index extensions are optional, including TREE. I think "link" is the only one that the readers that do not understand it are told to abort without causing damage. > present 99% of time when a different git impl reads an index created > by C Git. This 'EIOE' may be a good test then to see if they follow > the "ignore optional extensions" rule since it will always appear in > new C Git releases. I think we probably should squelch "ignoring unknown" unless some sort of GIT_TRACE/DEBUG switch is set. Patches welcome ;-) Thanks.
Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
On Mon, Sep 17, 2018 at 7:31 PM Junio C Hamano wrote: > > Duy Nguyen writes: > > > But it _is_ available now. If you need it, you write the extension > > out. > > Are you arguing for making it omitted when it is not needed (e.g. > small enough index file)? IOW, did you mean "If you do not need it, > you do not write it out" by the above? Yes I did. > I do not think overhead of writing (or preparing to write) the > extension for a small index file is by definition small enough ;-). Good point. I get annoyed by the "ignoring unknown extension xxx" messages while testing though (not just this extension) and I think it will be the same for other git implementations. But perhaps other implementations just silently drop the extension. Most of the extensions we have added so far (except the ancient 'TREE') are optional and are probably not present 99% of time when a different git impl reads an index created by C Git. This 'EIOE' may be a good test then to see if they follow the "ignore optional extensions" rule since it will always appear in new C Git releases. -- Duy
Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
Duy Nguyen writes: > But it _is_ available now. If you need it, you write the extension > out. Are you arguing for making it omitted when it is not needed (e.g. small enough index file)? IOW, did you mean "If you do not need it, you do not write it out" by the above? I do not think overhead of writing (or preparing to write) the extension for a small index file is by definition small enough ;-). I do not think the configuration that decides if the reader side uses parallel reading should have any say in the decision to write (or omit) the extension, by the way.
Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
On Mon, Sep 17, 2018 at 4:55 PM Ben Peart wrote:
> On 9/15/2018 6:02 AM, Duy Nguyen wrote:
>
> >> default:
> >> if (*ext < 'A' || 'Z' < *ext)
> >> return error("index uses %.4s extension, which we
> >> do not understand",
> >> @@ -1889,6 +1893,11 @@ static size_t estimate_cache_size(size_t
> >> ondisk_size, unsigned int entries)
> >> return ondisk_size + entries * per_entry;
> >> }
> >>
> >> +#ifndef NO_PTHREADS
> >> +static unsigned long read_eoie_extension(void *mmap_, size_t mmap_size);
> >> +#endif
> >
> > Keep functions unconditionally built as much as possible. I don't see
> > why this read_eoie_extension() must be built only on multithread
> > platforms.
> >
>
> This is conditional to avoid generating a warning on single threaded
> platforms where the function is currently unused. That seemed like a
> better choice than calling it and ignoring it on single threaded
> platforms just to avoid a compiler warning.
The third option is ignore the compiler. I consider that warning a
helpful suggestion, not a strict rule.
Most devs don't run single thread builds (I think) so is this function
is updated in a way that breaks single thread mode, it can only be
found out when this function is used in single thread mode. At that
point the function may have changed a lot. If it's built
unconditionally, at least single thread users will yell up much sooner
and we could fix it much earlier.
> >> @@ -2520,11 +2534,13 @@ static int do_write_index(struct index_state
> >> *istate, struct tempfile *tempfile,
> >> return err;
> >>
> >> /* Write extension data here */
> >> + offset = lseek(newfd, 0, SEEK_CUR) + write_buffer_len;
> >> + the_hash_algo->init_fn(_c);
> >
> > Don't write (or even calculate to write it) unless it's needed. Which
> > means only do this when parallel reading is enabled and the index size
> > large enough, or when a test variable is set so you can force writing
> > this extension.
>
> I made the logic always write the extension based on the earlier
> discussion [1] where it was suggested this should have been part of the
> original index format for extensions from the beginning. This helps
> ensure it is available for current and future uses we haven't even
> discovered yet.
But it _is_ available now. If you need it, you write the extension
out. If we make this part of index version 5 (and make it not an
extension anymore) then I buy that argument. As it is, it's an
optional extension.
> [1] https://public-inbox.org/git/xmqqwp2s1h1x@gitster.mtv.corp.google.com/
>
>
> >> +
> >> +static void write_eoie_extension(struct strbuf *sb, git_hash_ctx
> >> *eoie_context, unsigned long offset)
> >
> > We normally just put function implementations before it's used to
> > avoid static forward declaration. Any special reason why it's not done
> > here?
> >
>
> This was done to promote readability of the (already large) read-cache.c
> file. I first considered moving the EOIE read/write functions into a
> separate file entirely but they need access to information only
> available within read-cache.c so I compromised and moved them to the end
> of the file instead.
I consider grouping extension related functions closer to
read_index_extension gives better readability, or at least better than
just putting new functions at the end in no particular order. But I
guess this is personal view.
--
Duy
Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
On 9/15/2018 6:02 AM, Duy Nguyen wrote:
default:
if (*ext < 'A' || 'Z' < *ext)
return error("index uses %.4s extension, which we do not
understand",
@@ -1889,6 +1893,11 @@ static size_t estimate_cache_size(size_t ondisk_size,
unsigned int entries)
return ondisk_size + entries * per_entry;
}
+#ifndef NO_PTHREADS
+static unsigned long read_eoie_extension(void *mmap_, size_t mmap_size);
+#endif
Keep functions unconditionally built as much as possible. I don't see
why this read_eoie_extension() must be built only on multithread
platforms.
This is conditional to avoid generating a warning on single threaded
platforms where the function is currently unused. That seemed like a
better choice than calling it and ignoring it on single threaded
platforms just to avoid a compiler warning.
+static void write_eoie_extension(struct strbuf *sb, git_hash_ctx
*eoie_context, unsigned long offset);
+
/* remember to discard_cache() before reading a different cache! */
int do_read_index(struct index_state *istate, const char *path, int
must_exist)
{
@@ -2198,11 +2207,15 @@ static int ce_write(git_hash_ctx *context, int fd, void
*data, unsigned int len)
return 0;
}
-static int write_index_ext_header(git_hash_ctx *context, int fd,
- unsigned int ext, unsigned int sz)
+static int write_index_ext_header(git_hash_ctx *context, git_hash_ctx
*eoie_context,
+ int fd, unsigned int ext, unsigned int sz)
{
ext = htonl(ext);
sz = htonl(sz);
+ if (eoie_context) {
+ the_hash_algo->update_fn(eoie_context, , 4);
+ the_hash_algo->update_fn(eoie_context, , 4);
+ }
return ((ce_write(context, fd, , 4) < 0) ||
(ce_write(context, fd, , 4) < 0)) ? -1 : 0;
}
@@ -2445,7 +2458,7 @@ static int do_write_index(struct index_state *istate,
struct tempfile *tempfile,
{
uint64_t start = getnanotime();
int newfd = tempfile->fd;
- git_hash_ctx c;
+ git_hash_ctx c, eoie_c;
struct cache_header hdr;
int i, err = 0, removed, extended, hdr_version;
struct cache_entry **cache = istate->cache;
@@ -2454,6 +2467,7 @@ static int do_write_index(struct index_state *istate,
struct tempfile *tempfile,
struct ondisk_cache_entry_extended ondisk;
struct strbuf previous_name_buf = STRBUF_INIT, *previous_name;
int drop_cache_tree = istate->drop_cache_tree;
+ unsigned long offset;
for (i = removed = extended = 0; i < entries; i++) {
if (cache[i]->ce_flags & CE_REMOVE)
@@ -2520,11 +2534,13 @@ static int do_write_index(struct index_state *istate,
struct tempfile *tempfile,
return err;
/* Write extension data here */
+ offset = lseek(newfd, 0, SEEK_CUR) + write_buffer_len;
+ the_hash_algo->init_fn(_c);
Don't write (or even calculate to write it) unless it's needed. Which
means only do this when parallel reading is enabled and the index size
large enough, or when a test variable is set so you can force writing
this extension.
I made the logic always write the extension based on the earlier
discussion [1] where it was suggested this should have been part of the
original index format for extensions from the beginning. This helps
ensure it is available for current and future uses we haven't even
discovered yet.
[1]
https://public-inbox.org/git/xmqqwp2s1h1x@gitster.mtv.corp.google.com/
+
+static void write_eoie_extension(struct strbuf *sb, git_hash_ctx
*eoie_context, unsigned long offset)
We normally just put function implementations before it's used to
avoid static forward declaration. Any special reason why it's not done
here?
This was done to promote readability of the (already large) read-cache.c
file. I first considered moving the EOIE read/write functions into a
separate file entirely but they need access to information only
available within read-cache.c so I compromised and moved them to the end
of the file instead.
+{
+ uint32_t buffer;
+ unsigned char hash[GIT_MAX_RAWSZ];
+
+ /* offset */
+ put_be32(, offset);
+ strbuf_add(sb, , sizeof(uint32_t));
+
+ /* hash */
+ the_hash_algo->final_fn(hash, eoie_context);
+ strbuf_add(sb, hash, the_hash_algo->rawsz);
+}
diff --git a/t/README b/t/README
index 9028b47d92..d8754dd23a 100644
--- a/t/README
+++ b/t/README
@@ -319,6 +319,11 @@ GIT_TEST_OE_DELTA_SIZE= exercises the uncomon
pack-objects code
path where deltas larger than this limit require extra memory
allocation for bookkeeping.
+GIT_TEST_DISABLE_EOIE= disables writing the EOIE extension.
+This is used to allow tests 1, 4-9 in t1700-split-index.sh to succeed
I have a feeling that you won't have problems if you don't write eoie
extension by default in the first place. Then this could be
Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
On Wed, Sep 12, 2018 at 6:18 PM Ben Peart wrote:
>
> The End of Index Entry (EOIE) is used to locate the end of the variable
> length index entries and the beginning of the extensions. Code can take
> advantage of this to quickly locate the index extensions without having
> to parse through all of the index entries.
>
> Because it must be able to be loaded before the variable length cache
> entries and other index extensions, this extension must be written last.
> The signature for this extension is { 'E', 'O', 'I', 'E' }.
>
> The extension consists of:
>
> - 32-bit offset to the end of the index entries
>
> - 160-bit SHA-1 over the extension types and their sizes (but not
> their contents). E.g. if we have "TREE" extension that is N-bytes
> long, "REUC" extension that is M-bytes long, followed by "EOIE",
> then the hash would be:
>
> SHA-1("TREE" + +
> "REUC" + )
>
> Signed-off-by: Ben Peart
> ---
> Documentation/technical/index-format.txt | 23
> read-cache.c | 154 +--
> t/README | 5 +
> t/t1700-split-index.sh | 1 +
> 4 files changed, 175 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/technical/index-format.txt
> b/Documentation/technical/index-format.txt
> index db3572626b..6bc2d90f7f 100644
> --- a/Documentation/technical/index-format.txt
> +++ b/Documentation/technical/index-format.txt
> @@ -314,3 +314,26 @@ The remaining data of each directory block is grouped by
> type:
>
>- An ewah bitmap, the n-th bit indicates whether the n-th index entry
> is not CE_FSMONITOR_VALID.
> +
> +== End of Index Entry
> +
> + The End of Index Entry (EOIE) is used to locate the end of the variable
> + length index entries and the begining of the extensions. Code can take
> + advantage of this to quickly locate the index extensions without having
> + to parse through all of the index entries.
> +
> + Because it must be able to be loaded before the variable length cache
> + entries and other index extensions, this extension must be written last.
> + The signature for this extension is { 'E', 'O', 'I', 'E' }.
> +
> + The extension consists of:
> +
> + - 32-bit offset to the end of the index entries
> +
> + - 160-bit SHA-1 over the extension types and their sizes (but not
> + their contents). E.g. if we have "TREE" extension that is N-bytes
> + long, "REUC" extension that is M-bytes long, followed by "EOIE",
> + then the hash would be:
> +
> + SHA-1("TREE" + +
> + "REUC" + )
> diff --git a/read-cache.c b/read-cache.c
> index 7b1354d759..858935f123 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -43,6 +43,7 @@
> #define CACHE_EXT_LINK 0x6c696e6b/* "link" */
> #define CACHE_EXT_UNTRACKED 0x554E5452 /* "UNTR" */
> #define CACHE_EXT_FSMONITOR 0x46534D4E /* "FSMN" */
> +#define CACHE_EXT_ENDOFINDEXENTRIES 0x454F4945 /* "EOIE" */
>
> /* changes that can be kept in $GIT_DIR/index (basically all extensions) */
> #define EXTMASK (RESOLVE_UNDO_CHANGED | CACHE_TREE_CHANGED | \
> @@ -1693,6 +1694,9 @@ static int read_index_extension(struct index_state
> *istate,
> case CACHE_EXT_FSMONITOR:
> read_fsmonitor_extension(istate, data, sz);
> break;
> + case CACHE_EXT_ENDOFINDEXENTRIES:
> + /* already handled in do_read_index() */
> + break;
Perhaps catch this extension when it's not written at the end (e.g. by
some other git implementation) and warn.
> default:
> if (*ext < 'A' || 'Z' < *ext)
> return error("index uses %.4s extension, which we do
> not understand",
> @@ -1889,6 +1893,11 @@ static size_t estimate_cache_size(size_t ondisk_size,
> unsigned int entries)
> return ondisk_size + entries * per_entry;
> }
>
> +#ifndef NO_PTHREADS
> +static unsigned long read_eoie_extension(void *mmap_, size_t mmap_size);
> +#endif
Keep functions unconditionally built as much as possible. I don't see
why this read_eoie_extension() must be built only on multithread
platforms.
> +static void write_eoie_extension(struct strbuf *sb, git_hash_ctx
> *eoie_context, unsigned long offset);
> +
> /* remember to discard_cache() before reading a different cache! */
> int do_read_index(struct index_state *istate, const char *path, int
> must_exist)
> {
> @@ -2198,11 +2207,15 @@ static int ce_write(git_hash_ctx *context, int fd,
> void *data, unsigned int len)
> return 0;
> }
>
> -static int write_index_ext_header(git_hash_ctx *context, int fd,
> - unsigned int ext, unsigned int sz)
> +static int write_index_ext_header(git_hash_ctx *context, git_hash_ctx
> *eoie_context,
> + int fd, unsigned int ext, unsigned int sz)
> {
> ext = htonl(ext);
> sz = htonl(sz);
> + if (eoie_context) {
> +
Re: [PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
Ben Peart writes: > diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh > index 39133bcbc8..f613dd72e3 100755 > --- a/t/t1700-split-index.sh > +++ b/t/t1700-split-index.sh > @@ -7,6 +7,7 @@ test_description='split index mode tests' > # We need total control of index splitting here > sane_unset GIT_TEST_SPLIT_INDEX > sane_unset GIT_FSMONITOR_TEST > +export GIT_TEST_DISABLE_EOIE=true > > test_expect_success 'enable split index' ' > git config splitIndex.maxPercentChange 100 && It is safer to squash the following in; we may want to revisit the decision test-lint makes on this issue later, though. -- >8 -- Subject: [PATCH] SQUASH??? http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#export specifies how "export name[=word]" ought to work, but because writing "name=word; export name" is not so much more cumbersome and some older shells that do not understand the former do grok the latter. test-lint also recommends spelling it this way. --- t/t1700-split-index.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index f613dd72e3..dab97c2187 100755 --- a/t/t1700-split-index.sh +++ b/t/t1700-split-index.sh @@ -7,7 +7,7 @@ test_description='split index mode tests' # We need total control of index splitting here sane_unset GIT_TEST_SPLIT_INDEX sane_unset GIT_FSMONITOR_TEST -export GIT_TEST_DISABLE_EOIE=true +GIT_TEST_DISABLE_EOIE=true; export GIT_TEST_DISABLE_EOIE test_expect_success 'enable split index' ' git config splitIndex.maxPercentChange 100 && -- 2.19.0
[PATCH v5 1/5] eoie: add End of Index Entry (EOIE) extension
The End of Index Entry (EOIE) is used to locate the end of the variable
length index entries and the beginning of the extensions. Code can take
advantage of this to quickly locate the index extensions without having
to parse through all of the index entries.
Because it must be able to be loaded before the variable length cache
entries and other index extensions, this extension must be written last.
The signature for this extension is { 'E', 'O', 'I', 'E' }.
The extension consists of:
- 32-bit offset to the end of the index entries
- 160-bit SHA-1 over the extension types and their sizes (but not
their contents). E.g. if we have "TREE" extension that is N-bytes
long, "REUC" extension that is M-bytes long, followed by "EOIE",
then the hash would be:
SHA-1("TREE" + +
"REUC" + )
Signed-off-by: Ben Peart
---
Documentation/technical/index-format.txt | 23
read-cache.c | 154 +--
t/README | 5 +
t/t1700-split-index.sh | 1 +
4 files changed, 175 insertions(+), 8 deletions(-)
diff --git a/Documentation/technical/index-format.txt
b/Documentation/technical/index-format.txt
index db3572626b..6bc2d90f7f 100644
--- a/Documentation/technical/index-format.txt
+++ b/Documentation/technical/index-format.txt
@@ -314,3 +314,26 @@ The remaining data of each directory block is grouped by
type:
- An ewah bitmap, the n-th bit indicates whether the n-th index entry
is not CE_FSMONITOR_VALID.
+
+== End of Index Entry
+
+ The End of Index Entry (EOIE) is used to locate the end of the variable
+ length index entries and the begining of the extensions. Code can take
+ advantage of this to quickly locate the index extensions without having
+ to parse through all of the index entries.
+
+ Because it must be able to be loaded before the variable length cache
+ entries and other index extensions, this extension must be written last.
+ The signature for this extension is { 'E', 'O', 'I', 'E' }.
+
+ The extension consists of:
+
+ - 32-bit offset to the end of the index entries
+
+ - 160-bit SHA-1 over the extension types and their sizes (but not
+ their contents). E.g. if we have "TREE" extension that is N-bytes
+ long, "REUC" extension that is M-bytes long, followed by "EOIE",
+ then the hash would be:
+
+ SHA-1("TREE" + +
+ "REUC" + )
diff --git a/read-cache.c b/read-cache.c
index 7b1354d759..858935f123 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -43,6 +43,7 @@
#define CACHE_EXT_LINK 0x6c696e6b/* "link" */
#define CACHE_EXT_UNTRACKED 0x554E5452 /* "UNTR" */
#define CACHE_EXT_FSMONITOR 0x46534D4E /* "FSMN" */
+#define CACHE_EXT_ENDOFINDEXENTRIES 0x454F4945 /* "EOIE" */
/* changes that can be kept in $GIT_DIR/index (basically all extensions) */
#define EXTMASK (RESOLVE_UNDO_CHANGED | CACHE_TREE_CHANGED | \
@@ -1693,6 +1694,9 @@ static int read_index_extension(struct index_state
*istate,
case CACHE_EXT_FSMONITOR:
read_fsmonitor_extension(istate, data, sz);
break;
+ case CACHE_EXT_ENDOFINDEXENTRIES:
+ /* already handled in do_read_index() */
+ break;
default:
if (*ext < 'A' || 'Z' < *ext)
return error("index uses %.4s extension, which we do
not understand",
@@ -1889,6 +1893,11 @@ static size_t estimate_cache_size(size_t ondisk_size,
unsigned int entries)
return ondisk_size + entries * per_entry;
}
+#ifndef NO_PTHREADS
+static unsigned long read_eoie_extension(void *mmap_, size_t mmap_size);
+#endif
+static void write_eoie_extension(struct strbuf *sb, git_hash_ctx
*eoie_context, unsigned long offset);
+
/* remember to discard_cache() before reading a different cache! */
int do_read_index(struct index_state *istate, const char *path, int must_exist)
{
@@ -2198,11 +2207,15 @@ static int ce_write(git_hash_ctx *context, int fd, void
*data, unsigned int len)
return 0;
}
-static int write_index_ext_header(git_hash_ctx *context, int fd,
- unsigned int ext, unsigned int sz)
+static int write_index_ext_header(git_hash_ctx *context, git_hash_ctx
*eoie_context,
+ int fd, unsigned int ext, unsigned int sz)
{
ext = htonl(ext);
sz = htonl(sz);
+ if (eoie_context) {
+ the_hash_algo->update_fn(eoie_context, , 4);
+ the_hash_algo->update_fn(eoie_context, , 4);
+ }
return ((ce_write(context, fd, , 4) < 0) ||
(ce_write(context, fd, , 4) < 0)) ? -1 : 0;
}
@@ -2445,7 +2458,7 @@ static int do_write_index(struct index_state *istate,
struct tempfile *tempfile,
{
uint64_t start = getnanotime();
int newfd = tempfile->fd;
- git_hash_ctx c;
+ git_hash_ctx c, eoie_c;
struct cache_header hdr;
int i, err = 0, removed,
