On 02/26/2011 12:30 AM, Johns Daniel wrote: > What is the reason was for having random filenames for the SQLite > master journal file (like mine.db-mj501CA440, mine.db-mj1C17CCCC, > mine.db-mj66677495, etc)? > > Here is the reason for this strange question. We have discovered that > the JFFS2 filesystem in Linux is leaking kernel memory each time we > open/close/delete a file with a different name! I have not figured out > how to fix the leak in JFFS2 yet. I was wondering whether this > workaround is safe: Change our SQLite code to always use a fixed > filename (like mine.db-mjMASTER).
The problem is that if a crash occurs during a multi-file commit, the master journal cannot be removed from the file-system until the transactions have been rolled back for all database files. And this doesn't happen until the first time each of them is read. For example, say you have two databases in a transaction - mine.db and yours.db. A crash happens while committing the transaction and the file mine.db-mjMASTER is left in the file-system. Following recovery, if a process tries to read mine.db, the transaction on mine.db will be rolled back. But the master journal file cannot be deleted yet (since the interrupted transaction on yours.db has not yet been reverted). If the process then attaches "ours.db" and then tries to write a multi-file transaction that involves mine.db and ours.db it has a problem - it wants to create and populate mine.db-mjMASTER but it cannot, since that file is still in use. We use the random names to get around this problem. You could probably get away with using "-mjMASTER1", "-mjMASTER2" etc. if you wanted to. See the loop around line 1729 of vdbeaux.c. Dan. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
