Re: Berkeley DB 6.0 license change to AGPLv3

[Florian Weimer <fw@deneb.enyo.de>]

* Howard Chu:

> We require that fsync() (actually fdatasync()) doesn't lie. Data pages
> can be written in any order, as long as all outstanding data pages are
> actually written by the time fsync returns. Given this constraint, you
> can pull the power on a drive and the DB will still be fine.

And you do an fsync() as part of every transaction commit?  Doesn't
this force quite a bit of non-sequential writes?  (Page 0 or 1, plus
all the pages written to during the transaction.)

It's curious that this results in competitive write performance.
(WAL-based systems only need one sequential write during transaction
commit.)  Perhaps spreading out the writes at commit is worth all the
seeking and the potentially redudant writes because it avoids
write-induced stalls at checkpoints (or compaction events or whatever
databases do to look good in benchmarks but fall over in practice :-).