On Mon, Aug 17, 2009 at 11:53 AM, D. Richard Hipp <[email protected]> wrote:
> > On Aug 17, 2009, at 11:41 AM, Matt Sergeant wrote: > > > > Kernels will fflush when a file handle is closed > > Not according to Ted Ts'o (creator of the Ext2/3/4 filesystems). See, > for example, the extensive discussions of this at > > > http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ > http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/ > > Ted says that it is widely believed among programmers that close() > will sync a file, but in fact nothing in POSIX requires this and in > fact Linux does not do it. Some hacks were added to ext4 in the > 2.6.30 kernel release to mitigate the damage following a power loss > when programs fail to fsync() prior to close(). But everybody agrees > those changes are an ugly hack. > > In POSIX, the bottom line is this: The *only* way to force data to > oxide is to call sync() or fsync(). Some kernels and/or some > filesystems might sync at other times, but it is not something that > you can rely on. > > D. Richard Hipp > [email protected] > To the original question though, with PRAGMA synchronous=OFF, SQLite will NOT do explicit fsync()'s. A exception to this occurs with attached DB's and a transaction; when the transaction is committed and the master journal is deleted, SQLite fsyncs the directory that contained the journal to ensure the delete is "flushed". The only way around this fsync() is to compile with SQLITE_DISABLE_DIRSYNC. This might be changed in the future. -Shane _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
