On 24 Oct 2012, at 10:17pm, Nico Williams <n...@cryptonector.com> wrote:
> That [cache flushing] is not what's being asked for here. Just a > light-weight barrier. My proposal works without having to add new > system calls: a) use a COW format, b) have background threads doing > fsync()s, c) in each transaction's root block note the last > known-committed (from a completed fsync()) transaction's root block, Nico, A) fsync() doesn't work the way it's meant to on the majority of user platforms. It effectively does nothing. Here are typical notes for Windows Server and FreeBSD: <https://jira.mongodb.org/browse/SERVER-728> "fsync shouldn't be a noop on windows" <http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013871.html> "The fsync appears to be a noop." I'm not knocking any particular OS, they're all like that. Because actually implementing fsync() causes massive slow-downs on all disk writes, and makes the computer feel unresponsive to users. B) Your hard disk lies. Unless it's a server-level (i.e. expensive) hard disk sold especially for server use, it does not enforce in-order writing, either at the firmware level or the driver level. Protocols like SCSI have ways to do this correctly, but the overwhelming majority of IDE controllers out there will just completely ignore it. Again, I'm not knocking a particular model, they're all like that. Because write-back caching is so much faster and implementing write-through caching as well takes additional programming for something most users will never use. To propose a new utility which rides above the operating system, both of the above have to be remedied. Your call depends on the OS not lying, and the OS depends on the hardware not lying. You cannot fix this at the level you propose. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
