Differences From:
File www/selfcheck.wiki part of check-in [904ee40b93] - Change "baseline" to "check-in" in the on-line documentation. by drh on 2009-01-23 00:16:26. [view]
To:
File www/selfcheck.wiki part of check-in [7a2c37063a] - merge trunk into creole branch by bob on 2009-09-22 07:49:39. Also file www/selfcheck.wiki part of check-in [522824b26a] - Documentation updates, including a big rework of the homepage. by drh on 2009-08-28 16:05:03. [view]
@@ -1,27 +1,21 @@ -<nowiki> -<h1 align="center"> -Fossil Repository Integrity Self-Checks -</h1> - -<p> -Even though fossil is a relatively new project and still contains -many bugs, it is designed with features to give it a high level -of integrity so that you can have confidence that you will not -lose your files. This note describes the defensive measures that -fossil uses to help prevent file loss due to bugs. -</p> - -<p><i>Follow-up as of 2007-11-24:</i> -<i>Reiterated on 2008-05-16 and again on 2008-10-04:</i> +<title>Fossil Repository Integrity Self-Checks</title> + +<h1 align="center">Fossil Repository Integrity Self-Checks</h1> + +Fossil is designed with features to give it a high level +of integrity so that users can have confidence that content will +never be mangled or lost by Fossil. +This note describes the defensive measures that +Fossil uses to help prevent information loss due to bugs. + Fossil has been hosting itself and many other projects for -months now. Many bugs have been encountered. But, thanks in large +years now. Many bugs have been encountered. But, thanks in large part to the defensive measures described here, no data has been lost. The integrity checks are doing their job well.</p> <h2>Atomic Check-ins With Rollback</h2> -<p> The fossil repository is an <a href="http://www.sqlite.org/">SQLite version 3</a> database file. SQLite is very mature and stable and has been in wide-spread use for many years, so we are confident it will not cause repository @@ -29,20 +23,16 @@ databases do not corrupt even if a program or system crash or power failure occurs in the middle of the update. If some kind of crash does occur in the middle of a change, then all the changes are rolled back the next time that the database is accessed. -</p> - -<p> + A check-in operation in fossil makes many changes to the repository database. But all these changes happen within a single transaction. If something goes wrong in the middle of the commit, then the transaction is rolled back and the database is unchanged. -</p> <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> -<p> The content files that comprise the global state of a fossil respository are stored in the repository as a tree. The leaves of the tree are stored as zlib-compressed BLOBs. Interior nodes are deltas from their decendants. A lot of encoding is going on. There is @@ -50,11 +40,9 @@ cause corruption if used improperly. And there is the relatively new delta-encoding mechanism designed expressly for fossil. We want to make sure that bugs in these encoding mechanisms do not lead to loss of data. -</p> - -<p> + To increase our confidence that everything in the repository is recoverable, fossil makes sure it can extract an exact replicate of every content file that it changes just prior to transaction commit. So during the course of check-in (or other repository @@ -67,21 +55,17 @@ the original content of all files that were written, computes the SHA1 checksum again, and verifies that the checksums match. If anything does not match up, an error message is printed and the transaction rolls back. -</p> - -<p> + So, in other words, fossil always checks to make sure it can re-extract a file before it commits a change to that file. Hence bugs in fossil are unlikely to corrupt the repository in a way that prevents us from extracting historical versions of files. -</p> <h2>Checksum Over All Files In A Check-in</h2> -<p> Manifest artifacts that define a check-in have two fields (the R-card and Z-card) that record MD5 hashs of the manifest itself and of all other files in the manifest. Prior to any check-in commit, these checksums are verified to ensure that the check-in @@ -90,5 +74,32 @@ sure that the entire repository was checked out correctly. Note that these added checks use a different hash (MD5 instead of SHA1) in order to avoid common-mode failures in the hash algorithm implementation. -</p> + + +<h2>Checksums On Control Artifacts And Deltas</h2> + +Every [./fileformat.wiki | control artifact] in a fossil repository +contains a "Z-card" bearing an MD5 checksum over the rest of the +artifact. Any mismatch causes the control artifact to be ignored. + +The [./delta_format.wiki | file delta format] includes a 32-bit +checksum of the target file. Whenever a file is reconstructed from +a delta, that checksum is verified to make sure the reconstruction +was done correctly. + +<h2>Reliability Versus Performance</h2> + +Some version control systems make a big deal out of being "high performance" +or the "fastest version control system". Fossil makes no such claims and has +no such ambition. Indeed, profiling indicates that fossil bears a +substantial performance cost for +doing all of the checksumming and verification outlined above. +Fossil takes the philosophy of the +<a href="http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare">tortoise</a>: +reliability is more important than raw speed. The developers of +fossil see no merit in getting the wrong answer quickly. + +Fossil may not be the fastest versioning system, but it is "fast enough". +Fossil runs quickly enough to stay out of the developers way. +Most operations complete in under a second.