On Wed, Oct 10, 2012 at 12:48 PM, Richard Hipp <d...@sqlite.org> wrote: >> Could you list the requirements of such a light weight barrier? >> i.e. what would it need to do minimally, what's different from >> fsync/fdatasync ? > > For SQLite, the write barrier needs to involve two separate inodes. The > requirement is this:
... > Note also that when fsync() works as advertised, SQLite transactions are > ACID. But when fsync() is reduced to a write-barrier, we loss the D > (durable) and transactions are only ACI. In our experience, nobody really > cares very much about durable across a power-loss. People are mainly > interested in Atomic, Consistent, and Isolated. If you take a power loss > and then after reboot you find the 10 seconds of work prior to the power > loss is missing, nobody much cares about that as long as all of the prior > work is still present and consistent. There is something you can do: use a combination of COW on-disk formats in such a way that it's possible to detect partially-committed transactions and rollback to the last good known root, and backgrounded fsync()s (i.e., in a separate thread, without waiting for the fsync() to complete). Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
