Documentation Source Text

Check-in [f4e38c11f1]
Login

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: f4e38c11f13f719e6403875491013a72143b801dbe903596f0d7b3ee7abb2a26
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
Unified Diff Ignore Whitespace Patch
Changes to pages/atomiccommit.in.
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
  manufactures 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







|







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
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 &mdash; storing the blob filenames as entries in the
database &mdash 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







|







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 &mdash; storing the blob filenames as entries in the
database &mdash; 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