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 git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
