Re: [ANNOUNCE] GIT 1.6.1

[Nicolas Pitre]

On Thu, 25 Dec 2008, Heikki Orsila wrote:

> On Wed, Dec 24, 2008 at 10:36:27PM -0800, Junio C Hamano wrote:
> > * The packfile machinery hopefully is more robust when dealing with
> >   corrupt packs if redundant objects involved in the corruption are
> >   available elsewhere.
> 
> Has anyone written a summary of how Git's redundancy operates?
> 
> * What would be the probability for a single bit flip to corrupt the 
> repository?

This is not something that git itself could answer.  The probability 
depends on the quality of your hardware.  Once that probability has 
occurred though, it is clear that your repository is then corrupted as 
there is hardly any redundant bits in a git repository.

> * And what is the situation where a single bit flip can not corrupt the 
> database?

The database can be resilient against most kind of corruptions if you 
have a redundant copy of the affected object.  It will still be 
corrupted, but git is now able to detect corruptions gracefully and 
function correctly with some fallback objects.  Those objects must exist 
in some other related repository though, and copied over to the affected 
repository manually. It's then possible and recommended to "fix" the 
corruption simply by repacking the repository at that point.

So there is no magic involved: you need to have some kind of backups, 
either using traditional backup solutions, or by simply having your 
repository cloned somewhere else.  The idea of having a repository fixed 
with redundant objects is for those cases where you need to salvage new 
work that has no corresponding backup, but although corresponding 
objects are not corrupted, they could be delta objects which base is 
against old objects which happen to be corrupted.

> * When (which commands/functions) is error detection done?

Error detection is performed all the time.  When it's not the more 
expensive SHA1 checksum, at least the zlib CRC32 is verified.  What the 
latest git version does amongst other corruption related things is to 
close some small holes where some specific kind of corruptions could 
have been undetected and propagated from one pack to another when 
repacking.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/