On Thu, Nov 1, 2012 at 8:38 PM, Howard Chu <h...@symas.com> wrote: > Alan Cox wrote: > >> How about that recently preliminary infrastructure to send ORDERED >>> commands >>> instead of queue draining was deleted from the kernel, because "there's >>> no >>> difference where to drain the queue, on the kernel or the storage side"? >>> >> >> Send patches. >> > > Isn't any type of kernel-side ordering an exercise in futility, since > a) the kernel has no knowledge of the disk's actual geometry > b) most drives will internally re-order requests anyway > c) cheap drives won't support barriers > > Even assuming the drives honored all your requests without lying, how > would you really want this behavior exposed? From the userland perspective, > there are very few apps that care. Probably only transactional databases, > really. > > As a DB author, I'm not sure I'd be keen on this as an open() or fcntl() > option. Databases that really care would be on dedicated filesystems and/or > devices, so per-file control would be tedious. You would most likely want > to say "all writes to this string of devices should be order-preserving" > and forget about it. With that guarantee, a careful writer can have > perfectly intact data structures all the time, without ever slowing down > for a fsync. > > SQLite cares. SQLite is an in-process, transaction, zero-configuration database that is estimated to be used by over 1 million distinct applications and to be have over 2 billion deployments. SQLite uses ordinary disk files in ordinary directories, often selected by the end-user. There is no system administrator with SQLite, so there is no opportunity to use a dedicated filesystem with special mount options.
SQLite uses fsync() as a write barrier to assure consistency following a power loss. In addition, we do everything we can to maximize the amount of time after the fsync() before we actually do another write where order matters, in the hopes that the writes will still be ordered on platforms where fsync() is ignored for whatever reason. Even so, we believe we could get a significant performance boost and reliability improvement if we had a reliable write barrier. > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/**project/<http://www.openldap.org/project/> > > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
