Quote:
Originally Posted by Aleron Ives
Which firmware introduced the constant filesystem dirty bit problem?
|
It's been an issue on and off for quite a while. The last 3 releases have had more of an issue on my Sage than on my Clara HD where I rarely see the issue. Even more fun, it's not a constant issue in my testing. On my Sage, it happens about 1 in 5 connects. The only constant that I see is that either the KoboReader.sqlite or the BookReader.sqlite database file will be accompanied by the <filename>.sqlite-wal (write-ahead log) and <filename>.sqlite-shm (shared memory). When the database is properly closed, the sqlite-wal and sqlite-shm files will be merged into the database and removed.
For now, my workaround is rebooting before the USB connection which forces a database shutdown.
As previously mentioned, Kobo is aware of the issue and it will be fixed—hopefully sooner than later.
Quote:
2.2. Write-Ahead Log (WAL) Files
A write-ahead log or WAL file is used in place of a rollback journal when SQLite is operating in WAL mode. As with the rollback journal, the purpose of the WAL file is to implement atomic commit and rollback. The WAL file is always located in the same directory as the database file and has the same name as the database file except with the 4 characters "-wal" appended. The WAL file is created when the first connection to the database is opened and is normally removed when the last connection to the database closes. However, if the last connection does not shutdown cleanly, the WAL file will remain in the filesystem and will be automatically cleaned up the next time the database is opened.
2.3. Shared-Memory Files
When operating in WAL mode, all SQLite database connections associated with the same database file need to share some memory that is used as an index for the WAL file. In most implementations, this shared memory is implemented by calling mmap() on a file created for this sole purpose: the shared-memory file. The shared-memory file, if it exists, is located in the same directory as the database file and has the same name as the database file except with the 4 characters "-shm" appended. Shared memory files only exist while running in WAL mode.
The shared-memory file contains no persistent content. The only purpose of the shared-memory file is to provide a block of shared memory for use by multiple processes all accessing the same database in WAL mode. If the VFS is able to provide an alternative method for accessing shared memory, then that alternative method might be used rather than the shared-memory file. For example, if PRAGMA locking_mode is set to EXCLUSIVE (meaning that only one process is able to access the database file) then the shared memory will be allocated from heap rather than out of the shared-memory file, and the shared-memory file will never be created.
The shared-memory file has the same lifetime as its associated WAL file. The shared-memory file is created when the WAL file is created and is deleted when the WAL file is deleted. During WAL file recovery, the shared memory file is recreated from scratch based on the contents of the WAL file being recovered.
|