Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Describe fake-capacity USB sticks on the How-To-Corrupt page. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
0a50332c304ec37c6087ed2508a3c94e |
User & Date: | drh 2012-01-11 21:16:09.505 |
Context
2012-01-13
| ||
18:28 | Update webpage in preparation for the 3.7.10 release. (check-in: fd5efdc2c1 user: drh tags: trunk) | |
2012-01-11
| ||
21:16 | Describe fake-capacity USB sticks on the How-To-Corrupt page. (check-in: 0a50332c30 user: drh tags: trunk) | |
16:56 | Fix typos in the psow.html document. (check-in: e771d11d93 user: drh tags: trunk) | |
Changes
Changes to pages/howtocorrupt.in.
︙ | ︙ | |||
222 223 224 225 226 227 228 | SQLite seem to run faster, but it also allows the operating system to freely reorder writes, which could result in database corruption if a power failure or hard reset occurs prior to all content reaching persistent storage.</p> <p>For maximum reliability and for robustness against database corruption, SQLite should always be run with its default synchronous setting of FULL.</p> | > | | | | > > > > > > > > > > > > > | 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 | SQLite seem to run faster, but it also allows the operating system to freely reorder writes, which could result in database corruption if a power failure or hard reset occurs prior to all content reaching persistent storage.</p> <p>For maximum reliability and for robustness against database corruption, SQLite should always be run with its default synchronous setting of FULL.</p> <tcl>hd_fragment hardwarefault</tcl> <h2>4.0 Disk Drive and Flash Memory Failures</h2> <p>An SQLite database can become corrupt if the file content changes due to a disk drive or flash memory failure. It is very rare, but disks will occasionally flip a bit in the middle of a sector.</p> <h3>4.1 Non-powersafe flash memory controllers</h3> <p>We are told that in some flash memory controllers the wear-leveling logic can cause random filesystem damage if power is interrupted during a write. This can manifest, for example, as random changes in the middle of a file that was not even open at the time of the power loss. So, for example, a device would be writing content into an MP3 file in flash memory when a power loss occurs, and that could result in an SQLite database being corrupted even though the database as not even in use at the time of the power loss.</p> <tcl>hd_fragment fakeusb</tcl> <h3>4.2 Fake capacity USB sticks</h3> <p>There are many fraudulent USB sticks in circulation that report to have a high capacity (ex: 8GB) but are really only capable of storing a much smaller amount (ex: 1GB). Attempts to write on these devices will often result in unrelated files being overwritten. Any use of a fraudulent flash memory device can easily lead to database corruption, therefore. Internet searches such as "fake capacity usb" will turn up lots of disturbing information about this problem. <h2>5.0 Memory corruption</h2> <p>SQLite is a C-library that runs in the same address space as the application that it serves. That means that stray pointers, buffer overruns, heap corruption, or other malfunctions in application can corrupt internal SQLite data structure and ultimately result in a corrupt database file. Normally these kinds of problems manifest themselves |
︙ | ︙ |