Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Updates to the psow and testing documents. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
d30b4960c1f3fdc6dee9392f0f5b3b52 |
User & Date: | drh 2012-01-03 15:14:48.010 |
Context
2012-01-05
| ||
12:36 | Add mention of torn pages to the PSOW document. (check-in: 776ba1e766 user: drh tags: trunk) | |
2012-01-03
| ||
15:14 | Updates to the psow and testing documents. (check-in: d30b4960c1 user: drh tags: trunk) | |
2012-01-02
| ||
15:48 | Document the change to PRAGMA cache_size in which a negative argument can be used to set the cache size in kibibytes. (check-in: 47c781b488 user: drh tags: trunk) | |
Changes
Changes to pages/psow.in.
︙ | ︙ | |||
8 9 10 11 12 13 14 | data preservation during a power loss. Powersafe overwrite is a boolean property: either the storage system has it or it does not. <p>We say that a system has the powersafe overwrite property if the following statement is true: <blockquote> | | | | | | | 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 | data preservation during a power loss. Powersafe overwrite is a boolean property: either the storage system has it or it does not. <p>We say that a system has the powersafe overwrite property if the following statement is true: <blockquote> <b>When an application writes a range of bytes in a file, no bytes outside of that range will change, even if the write occurs just before a crash or power failure.</b> </blockquote> <p>The powersafe overwrite property says nothing about the state of the bytes that were written. Those bytes might contain their old values, their new values, random values, or some combination of these. The powersafe overwrite property merely states that writes cannot change bytes outside of the range of bytes written. <p>In other words, powersafe overwrite means that there is no "collateral damage" when a power loss occurs while writing. Only those bytes actually being written might be damaged. <p>In practical terms, what the powersafe write property means is that when the disk controller detects an impending power loss, it finishes writing whatever sector it is working on prior to parking the heads. It means that individual sector writes will complete once started, even if there is a power loss. <p>Consider what would happen if disk sector writes are interrupted by a power loss. If an application writes two or three bytes in the middle of some file, the operating system will implement this by first reading the entire sector containing those bytes, making the change to the sector in memory, then writing the entire sector back to the disk. If a power loss occurs during the writeback and the sector was not completely written, then on the next read after reboot, error correcting codes in the sector will probably detect irrepariable damage and the disk controller will read out the sector as all zeros or all ones. Thus values will have changed outside of the range of the two or three bytes that were written at the application level - a violation of the powersafe overwrite property. <h2>SQLite Assumptions About Powersafe Overwrite</h2> |
︙ | ︙ | |||
71 72 73 74 75 76 77 | This had the effect of increasing write overhead on many databases. For a database with a [PRAGMA page_size] of 1024 (a very common choice) making a change to a single page in the database now requires SQLite to backup three other adjacent pages to the rollback journal, whereas formerly it only had to backup the one page that was changing. In [WAL mode], each transaction had to be padded out to the next 4096-byte boundary in the WAL file, rather than the next 512-byte | | | | | 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 | This had the effect of increasing write overhead on many databases. For a database with a [PRAGMA page_size] of 1024 (a very common choice) making a change to a single page in the database now requires SQLite to backup three other adjacent pages to the rollback journal, whereas formerly it only had to backup the one page that was changing. In [WAL mode], each transaction had to be padded out to the next 4096-byte boundary in the WAL file, rather than the next 512-byte boundary, resulting in thousands of extra bytes being written per transaction. <p>The extra write overhead prompted a reexamination of assumptions about powersafe overwrite. With modern disk drives, the capacity has become so large and the data density so great that a single sector is very small and writing a single sector takes very little time. We know that disk drives can detect an impending power loss and continue to operate for some small amount of time on residual energy because those drives are able to park their heads before spinning down. And so if an impending power loss is detectable by the disk controller, it seems reasonable that the controller will finish writing whatever sector it is current working on when the imminent power loss is first detected, prior to parking the heads, as long as doing so does not take too long, which it should not with small and dense sectors. Hence it seems reasonable to assume powersafe overwrite for modern disks. Indeed, BerkeleyDB has made this assumption for decades, we are told. Caution is advised though. As Roger Binns noted on the SQLite develpers mailing list: "'poorly written' should be the main assumption about drive firmware." <h2>Changes In SQLite Version 3.7.10</h2> |
︙ | ︙ |
Changes to pages/testing.in.
︙ | ︙ | |||
99 100 101 102 103 104 105 | <h1 align="center">How SQLite Is Tested</h1> <h2>1.0 Introduction</h2> <p>The reliability and robustness of SQLite is achieved in part by thorough and careful testing.</p> | | < | 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 | <h1 align="center">How SQLite Is Tested</h1> <h2>1.0 Introduction</h2> <p>The reliability and robustness of SQLite is achieved in part by thorough and careful testing.</p> <p>As of [version 3.7.8], the SQLite library consists of approximately <tcl>KB {$stat(coreSLOC)}</tcl> KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has <tcl> hd_puts "[expr {int($stat(totalSLOC)/$stat(coreSLOC))}] times as much" |
︙ | ︙ | |||
776 777 778 779 780 781 782 | <h2>10.0 Static Analysis</h2> <p>Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis includes looking at compiler warning messages and running the code through more in-depth analysis engines such as the [http://clang-analyzer.llvm.org/ | Clang Static Analyzer]. | < | < < > | | | < | | | | 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 | <h2>10.0 Static Analysis</h2> <p>Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis includes looking at compiler warning messages and running the code through more in-depth analysis engines such as the [http://clang-analyzer.llvm.org/ | Clang Static Analyzer]. SQLite compiles without warnings on GCC using the -Wall and -Wextra flags. And the Clang Static Analyzer finds nothing wrong with SQLite either. VC++ often will generate a number of warnings from SQLite source code, but the experience of SQLite developers is that VC++ warnings are of lower quality and can be safely ignored. Users are encouraged not to stress over VC++ warnings.</p> <p>Static analysis has not proven to be especially helpful in finding bugs in SQLite. Static analysis has found a few bugs in SQLite, but those are the exceptions. More bugs have been introduced into SQLite while trying to get it to compile without warnings than have been found by static analysis. <p>Our experience, then, is that static analysis is not especially helpful to maintaining high code quality and it is therefore deemphasized in SQLite development and maintenance.</p> <tcl>hd_fragment summary</tcl> <h2>11.0 Summary</h2> <p>SQLite is open source. This gives many people the idea that |
︙ | ︙ |