Documentation Source Text

Check-in [776ba1e766]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Add mention of torn pages to the PSOW document.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 776ba1e7664f91acd096efa2d5eb1aa4fa97c342
User & Date: drh 2012-01-05 12:36:01
Context
2012-01-09
13:40
Add a note about data types and the compress/uncompress functions to the FTS documentation. check-in: 8fadbd41ce user: dan tags: trunk
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
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/psow.in.

91
92
93
94
95
96
97

















98
99
100
101
102
103
104
...
128
129
130
131
132
133
134












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>

<p>The [VFS] for SQLite version 3.7.10 adds a new device characteristic 
named [SQLITE_IOCAP_POWERSAFE_OVERWRITE].  Database files that report this
characteristic are assumed to reside on storage systems that have the
powersafe overwrite property.
................................................................................
   file:somefile.db?psow=0
</blockquote>

<p>There is also a new [SQLITE_FCNTL_POWERSAFE_OVERWRITE] opcode for
the [sqlite3_file_control()] that allows
an application to query the powersafe overwrite property for a database
file.



















>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







 







>
>
>
>
>
>
>
>
>
>
>
>
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
...
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
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."

<tcl>hd_fragment tornpage {torn page}</tcl>
<h2>Torn Pages</h2>

<p>A torn page occurs when a database page is larger than a disk sector,
the database page is written to disk, but a power loss occurs prior to
all sectors of the database page being written.  Then, upon recovery, part of
the database page will have the old content while some other parts of the
page will have the new content.  Some database engines assume that 
page writes are atomic and hence a torn page is an unrecoverable error.
</p>

<p>SQLite never assumes that database page writes are atomic,
regardless of the PSOW setting.<sup>(1)</sup>
And hence SQLite is always able to automatically recover from torn pages
induced by a crash.  Enabling PSOW does not decrease SQLite's ability
to recover from a torn page.</p>

<h2>Changes In SQLite Version 3.7.10</h2>

<p>The [VFS] for SQLite version 3.7.10 adds a new device characteristic 
named [SQLITE_IOCAP_POWERSAFE_OVERWRITE].  Database files that report this
characteristic are assumed to reside on storage systems that have the
powersafe overwrite property.
................................................................................
   file:somefile.db?psow=0
</blockquote>

<p>There is also a new [SQLITE_FCNTL_POWERSAFE_OVERWRITE] opcode for
the [sqlite3_file_control()] that allows
an application to query the powersafe overwrite property for a database
file.

<hr>
<h2>Notes:</h2>
<ol><li value=1><p>
SQLite never assumes atomic page writes <em>in its default configurations</em>.
But a custom [VFS] can sets one of the 
[SQLITE_IOCAP_ATOMIC] bits in the result of the xDeviceCharacteristic()
method and then SQLite will assume that page writes are atomic.  The
application must supply a custom VFS to accomplish this, however, since
none of the standard VFSes will ever set any of the atomic bits in the
xDeviceCharacteristics() vector.
</ol>