git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Thomas Gummerer <t.gummerer@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@student.ethz.ch>,
	git@vger.kernel.org, mhagger@alum.mit.edu, pclouds@gmail.com,
	robin.rosenberg@dewire.com
Subject: Re: [PATCH/RFC v3 01/13] Move index v2 specific functions to their own file
Date: Fri, 10 Aug 2012 17:40:15 +0200	[thread overview]
Message-ID: <20120810154015.GF5127@tommy-fedora.scientificnet.net> (raw)
In-Reply-To: <7vobmilro1.fsf@alter.siamese.dyndns.org>

On 08/10, Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
> 
> > But I think the idea always was that any write that changes the basic
> > layout of the file (so that you would read something wrong) will need a
> > full rewrite.  Otherwise we're too far in DB land.
> >
> > Most updates will be
> > of the "update the stat and/or sha1 of a file" kind, anyway.
> 
> Yes, I agree the v5 format documented in the series does not let you
> do anything other than the kind of updates without rewriting [*1*]
> 
> But that does not fundamentally change the story that a new format
> and a new way to access the index to cope with larger projects would
> want to come up with a solution to address the competing read/write
> issue, or at least help to make it easier to solve the issue in the
> future.
> 
> "That problem is not new" is not an answer when the question is "We
> still have the problem".
> 
> 
> [Footnote]
> 
> *1* While my gut feeling matches your guess that the kind of updates
> would be the majority, I do not think anybody did numbers to
> substanticate it, which we may want to see happen.

Hrm anther way to solve this may be the following. The idea would be
to just check if the index_file changed basically using the same
heuristic we already use to detect file changes.  (use the stat data,
mtime, size, etc.)

With this code we do not rely on the crc sums to check if the index
needs to be re-read anymore and don't have a problem if part of the
index changes, after we read it (we know the index changed from its
mtime and can just re-read it).  Another thing that would have to
change is that we can't use die if a crc is wrong, but some return
code, but that shouldn't be a problem.  I'm not sure I'm not missing
something here though.

do {
	fd = open()
	fstat(fd, &st_old);
	mmap = xmmap(fd);
	verify_various_fields(mmap);
	istate->ops->read_index(istate,
				mmap,
				mmap_size));
	fstat(fd, &st_new);
	close(fd);
} while (stat_data_doesnt_match(st_old, st_new));

  reply	other threads:[~2012-08-10 15:40 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-08 11:17 [PATCH/RFC v3 0/13] Introduce index file format version 5 Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 01/13] Move index v2 specific functions to their own file Thomas Gummerer
2012-08-08 12:04   ` Nguyen Thai Ngoc Duy
2012-08-08 19:21     ` Thomas Gummerer
2012-08-09 22:02   ` Junio C Hamano
2012-08-09 22:54     ` Thomas Gummerer
2012-08-10  0:13     ` Junio C Hamano
2012-08-10  2:23       ` Nguyen Thai Ngoc Duy
2012-08-10 14:24     ` Thomas Rast
2012-08-10 14:58       ` Junio C Hamano
2012-08-10 15:40         ` Thomas Gummerer [this message]
2012-08-08 11:17 ` [PATCH/RFC v3 02/13] t2104: Don't fail for index versions other than [23] Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 03/13] t3700: Avoid interfering with the racy code Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 04/13] Add documentation of the index-v5 file format Thomas Gummerer
2012-08-09 22:41   ` Junio C Hamano
2012-08-09 23:10     ` Thomas Gummerer
2012-08-09 23:13     ` Junio C Hamano
2012-08-08 11:17 ` [PATCH/RFC v3 05/13] Make in-memory format aware of stat_crc Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 06/13] Read index-v5 Thomas Gummerer
2012-08-08 12:05   ` Nguyen Thai Ngoc Duy
2012-08-08 12:18     ` Johannes Sixt
2012-08-08 17:05     ` Junio C Hamano
2012-08-08 19:29     ` Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 07/13] Read resolve-undo data Thomas Gummerer
2012-08-09 22:51   ` Junio C Hamano
2012-08-09 23:23     ` Thomas Gummerer
2012-08-10  0:02       ` Junio C Hamano
2012-08-10  9:27         ` Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 08/13] Read cache-tree in index-v5 Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 09/13] Write index-v5 Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 10/13] Write index-v5 cache-tree data Thomas Gummerer
2012-08-08 11:17 ` [PATCH/RFC v3 11/13] Write resolve-undo data for index-v5 Thomas Gummerer
2012-08-08 11:18 ` [PATCH/RFC v3 12/13] update-index.c: always rewrite the index when index-version is given Thomas Gummerer
2012-08-08 11:18 ` [PATCH/RFC v3 13/13] p0002-index.sh: add perf test for the index formats Thomas Gummerer

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120810154015.GF5127@tommy-fedora.scientificnet.net \
    --to=t.gummerer@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.com \
    --cc=robin.rosenberg@dewire.com \
    --cc=trast@student.ethz.ch \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).