Hello,
This message may be off-topic in that I don't think the following issue
corresponds to a bug with SQLite, but it's something I've discovered
while using SQLite. Perhaps someone on the list has had a similar
experience or could make a suggestion.
A Linux 2.6/x86_64 system reports a "disk I/O error" (SQLITE_IOERR)
while generating a specific report from a SQLite database (SQLite
3.3.6). The database and temporary files are accessed through an NFS
mount. After running the program again with SQLite tracing enabled
(plus a bit more I added), I see that SQLITE_IOERR is returned by
unixRead() because read() unexpectedly returned 0!
Here's some relevant strace output:
open("/nfs/tmp/sqlite_dBjTG5bZdsqFVPb", O_RDWR|O_CREAT|O_EXCL, 0644) = 8
[...]
lseek(8, 193536, SEEK_SET) = 193536
write(8, "\n\0\0\0\30\0\222\0\0\266\0\332\0\376\1\"\1F\1l\1\222\1"...,
1024) = 1024
[...]
lseek(8, 226304, SEEK_SET) = 226304
write(8, "\n\0\0\0\30\0\240\0\0\240\0\304\0\350\1\f\0010\1T\1x\1"...,
1024) = 1024
lseek(8, 193536, SEEK_SET) = 193536
read(8, "", 1024) = 0
fstat(8, {st_mode=S_IFREG|0644, st_size=227328, ...}) = 0
The read() call shouldn't fail -- the same page was written to at the
beginning of the transaction! At least by the time fstat() is called,
the file is 227328 bytes long, so a read at an offset of 193536 should
not fail.
I'm suspecting that the NFS server in question is buggy or
misconfigured. Unfortunately I don't have access to either the NFS
server or the host running the program, so mainly all I can access is
some strace and SQLite tracing output.
Thanks for any suggestions,
Arun
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
