*** 16,18 ****
--- 16,75 ----
An archived copy of the shadows project web pages and the various papers referred to in this proposal can be found at: http://web.archive.org/web/20030622220243/http://www.cs.hut.fi/~ylo/shadows/shadows.html
====
+ _By drh on 2004-Apr-14:_ {linebreak}
+ I have three issues with the shadow pager idea, in no particular order:
+
+ 1: The algorithm is less than 17 years old. That means that for all I know,
+ it could be patented. Perhaps there is a submarine patent. Who knows.
+ I prefer not to expose SQLite to patent risk. The current implementation
+ uses 17+ year old technology exclusively.
+
+ 2: The shadow pager assumes that a one-sector disk write is an atomic
+ operation. Is that true of modern disks? I don't know but I'm guessing
+ not. When a power failure occurs, the voltage to the disk controller
+ begins to decay. At some point, the voltage drops below the point where
+ the disk controller can function. If that point happens to be when
+ the first 1/3rd of the sector has been written, it seems to me that
+ the next 2/3rds of the second would be unchanged, or perhaps overwritten
+ with garbage. The current implementation might lose the entire
+ database file if a power lose occurs during the write of an
+ i-node on an unjournalled file system, but on a filesystem with at
+ least meta-data journalling, a partial sector write does not corrupt
+ the database, as far as I am aware.
+
+ 3: Unless I missed something, the shadow pager allows a single write to
+ occur while a read is ongoing, but not two consecutive writes. For
+ example, the following is allowed:
+
+ |-- write ---|
+ |--------------------------- read ----------------------|
+
+ _: But this is now allows:
+
+ |-- write ---| |--- write ---|
+ |--------------------------- read ----------------------|
+
+ _: The reason that the second version will not work is that the first
+ write may have added formerly used blocks to the freelist and the
+ second write might overwrite those freelist blocks while the read
+ is still using them, resulting in data corruption. Unfortunately,
+ I cannot think of a method for locking the database in a way that
+ prevents a second write from starting while there are still pending
+ reads.
+
+ Ben Carlyle's proposal (or variations thereof) allows a write operation
+ to start while reads are still ongoing. The write cannot commit until
+ all the reads finish. But this still gives you some of what the
+ shadow pager offers. Specifically:
+
+ |-- write ---|
+ |-------- read -------|
+
+ The current implemention requires that all reads end before the write
+ begins. Like this:
+
+ |-- write ---|
+ |--- read ---|
+
+ The current plan is to stay conservative and implement a modified
+ version of the Carlyle proposal in version 3.0.
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|