Quoth Drake Wilson <dr...@dasyatidae.net>, on 2013-04-04 10:20:44 -0500:
> So it is perfectly okay to use unprotected mmap accesses if an I/O
> error on the file will already make the entire process uncontinuable.
> The question is whether this applies to arbitrary SQLite databases
> that an application may open, and I suspect that (a) it probably
> doesn't, and (b) this reliability transitivity behavior would be a
> significant departure from earlier SQLite versions.

Here is a much more direct and concrete example.  Referenced files may
be retrieved from:

  http://dasyatidae.net/files/2013/sqlite3-201304040051/

Here are the steps I used.  This is on a modern Debian GNU/Linux AMD64
system.

  - Compile kvserv.c along with an _earlier_ (probably system) version
    of SQLite than the snapshot amalgamation mentioned above---I used:

      gcc -std=c99 -o kvserv kvserv.c -lsqlite3 -lpthread -ldl

  - Mount a removable disk that you don't care about very much (I used
    a spare USB flash disk), and copy keyval1.db to it.  Unmount,
    unplug, replug, and remount the disk read-only.  The database is
    deliberately a few megabytes in size to reduce the chance that all
    of it will be read ahead into cache; I used:

      echo 1 | sudo tee /proc/sys/vm/drop_caches

    a bit ad-hoc to help ensure this, though it should not theoretically
    be necessary.

  - Symlink the copied file to keyval.db in the current directory (all
    the other files should be on a reliable local disk), and ensure
    UDP port 11105 is not in use.  Run kvserv.  In a separate
    terminal, run something akin to:

      socat - udp6-datagram:[::1]:11105

    (In retrospect I should have used a Unix-domain socket, but I do
    not have time to change it right now; I apologize for the
    inconvenience.)

  - Issue queries to the simple key-value server by entering keys, one
    per line, in the socat terminal.  In particular, the keys 'a',
    'b', and 'c' are defined in the given DB, along with all
    five-digit decimal numbers.  Responses should be returned
    beginning with "OK" followed by either result data or nothing.

  - Unplug the removable disk hard, simulating a media failure.  Issue
    additional queries.  Responses should be returned beginning with
    "NG", indicating that there was an error retrieving the requested
    data.

Repeating these steps, but compiling the application with the
sqlite3.c from the 201304040051 snapshot amalgamation that uses
unprotected mmap, causes the entire kvserv process to die with SIGBUS
as soon as a query tries to access the volume while it is unplugged.

Unless the design of kvserv.c is relevantly unreasonable, this should
help demonstrate the danger of switching SQLite to use unprotected
mmap by default.

   ---> Drake Wilson
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to