On Thu, Apr 4, 2013 at 11:44 AM, Drake Wilson <dr...@dasyatidae.net> wrote: > 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.
This is very sad. But really, the OS should cause kvserv to hang waiting for I/O from the device to complete (and you should get some indication, in dmesg, on the console, in a dialog -something- that there's a missing device that's needed). Sending SIGBUS because a device is missing is a bit heavy-handed of the kernel! In a situation where the filesystem is corrupted it's a bit more natural to expect a panic/oops/BSOD, or even just user-land equivalent (like SIGBUS). (Anyone who remembers what server rooms were like in the mid-90s will remember SCSI cables falling off and so on. That SunOS and Solaris would hang in such events was rather useful.) > Unless the design of kvserv.c is relevantly unreasonable, this should > help demonstrate the danger of switching SQLite to use unprotected > mmap by default. I doubt kvserv.c is doing anything wrong. I've not run your test though. And searches for linux removable media SIGBUS turn up very little. Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
