On Sun, 31 Jan 2016 20:27:56 -0700 Scott Robison <scott at casaderobison.com> wrote:
> On Sun, Jan 31, 2016 at 7:35 PM, Rowan Worth <rowanw at dugeo.com> wrote: > > > On 31 January 2016 at 03:56, James K. Lowden > > <jklowden at schemamania.org> wrote: > > > > > Surely SQLite does both -- fsync on file and directory -- as part > > > of a commit. That's not in doubt, is it? > > > > > > > No, SQLite does not. On COMMIT it fsyncs the database file and > > unlinks the journal[1], but does not fsync the directory. This is > > demonstrated by the logs in Stefan's initial post, and indeed the > > purpose of his patch was to introduce an fsync on the directory > > after unlinking the journal. > > > > Perhaps there could be a "paranoid" journal mode, where it first > zeros out the header ala persist, then truncates the file, then > deletes the file. Well, I would say there are four choices: 1. Something like you suggest, but just mark the "committed fact" in the log file. It would be enough to write "we're done here" at the end of the file, followed by fsync, followed by unlink. Then if the log file is found (undeleted) after a crash, the information in the file suffices. 2. Call fsync after unlink. 3. Call fsync after unlink if directory's extended attributes don't include FS_DIRSYNC_FL *or* the filesystem was mounted with MS_DIRSYNC. 4. For systems that support it (Linux 2.6+) just go ahead and set FS_DIRSYNC_FL. The 3rd option underscores the pitfalls of directory synchronization under Linux. NetBSD for example has neither option; afaik all directory operations are synchronous. (Posix doesn't mention it.) Personally, I like to keep things simple. Update & fsync the log file one last time before deleting it. Works on every system, and is impervious to future permutations to directory synchronization.
