Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Fix two minor typos. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | branch-3.20 |
Files: | files | file ages | folders |
SHA3-256: |
f4e38c11f13f719e6403875491013a72 |
User & Date: | drh 2017-09-27 09:47:43.177 |
Context
2017-09-29
| ||
12:10 | Fix typos and poor wording in cintro.html (check-in: becd70e3fa user: drh tags: branch-3.20) | |
2017-09-27
| ||
09:47 | Fix two minor typos. (check-in: f4e38c11f1 user: drh tags: branch-3.20) | |
2017-08-24
| ||
16:48 | Fix incorrect SHA3 hash on the 3.20.1 sqlite3.c file. (check-in: 4252537c27 user: drh tags: branch-3.20) | |
Changes
Changes to pages/atomiccommit.in.
︙ | ︙ | |||
63 64 65 66 67 68 69 | for flash memory is usually larger than 512 bytes. For these reasons, versions of SQLite beginning with 3.3.14 have a method in the OS interface layer that interrogates the underlying filesystem to find the true sector size. As currently implemented (version 3.5.0) this method still returns a hard-coded value of 512 bytes, since there is no standard way of discovering the true sector size on either Unix or Windows. But the method is available for embedded device | | | 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 | for flash memory is usually larger than 512 bytes. For these reasons, versions of SQLite beginning with 3.3.14 have a method in the OS interface layer that interrogates the underlying filesystem to find the true sector size. As currently implemented (version 3.5.0) this method still returns a hard-coded value of 512 bytes, since there is no standard way of discovering the true sector size on either Unix or Windows. But the method is available for embedded device manufacturers to tweak according to their own needs. And we have left open the possibility of filling in a more meaningful implementation on Unix and Windows in the future.</p> <p>SQLite has traditionally assumed that a sector write is <u>not</u> atomic. However, SQLite does always assume that a sector write is linear. By "linear" we mean that SQLite assumes that when writing a sector, the hardware begins at one end of the data and writes byte by byte until it gets to |
︙ | ︙ |
Changes to pages/fasterthanfs.in.
︙ | ︙ | |||
78 79 80 81 82 83 84 | at which direct file I/O becomes faster is smaller than it is in Gray's paper. <p> The [Internal Versus External BLOBs] article on this website is an earlier investigation (circa 2011) that uses the same approach as the Jim Gray paper — storing the blob filenames as entries in the | | | 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 | at which direct file I/O becomes faster is smaller than it is in Gray's paper. <p> The [Internal Versus External BLOBs] article on this website is an earlier investigation (circa 2011) that uses the same approach as the Jim Gray paper — storing the blob filenames as entries in the database — but for SQLite instead of SQL Server. <h1>How These Measurements Are Made</h1> <p>I/O performance is measured using the [https://www.sqlite.org/src/file/test/kvtest.c|kvtest.c] program |
︙ | ︙ |