[lkml]   [2008]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] GIT 1.6.1
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


 \ /
  Last update: 2008-12-27 02:59    [W:0.030 / U:0.676 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site