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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
