[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.021 / U:5.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site