j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438">Quote from: satoshi on November 25, 2010, 05:51:39 PM</a></div><div class="quote">Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.<br/></div><br/>Which of the <a href="http://en.wikipedia.org/wiki/ACID">ACID</a> properties do you need, while downloading?<br/><br/>Adding BDB records is simply appending to a log file, until you <a href="http://www.mathematik.uni-ulm.de/help/BerkeleyDB/ref/transapp/checkpoint.html">issue a checkpoint</a>. The checkpoint then updates the main database file.<br/><br/>Under a normal BDB transaction, you are guaranteed that each log record will be sync'd to disk platter, before the transaction commit succeeds. This is very strict, but required for full ACID. Enabling <a href="http://www.mathematik.uni-ulm.de/help/BerkeleyDB/api_c/env_set_flags.html">DB_TXN_NOSYNC</a> still gives you a lot:<br/><br/> "database integrity will be maintained, but if the application or system fails, it is possible<br/> some number of the most recently committed transactions may be undone during recovery"<br/><br/>bitcoin can obviously recover if recent transactions are undone, so, it seems useful for this flag to be set for 100% of the initial block download.<br/><br/>That leaves checkpointing, which is a balance between amount of work performed at checkpoint time -- number of records that must be copied from log to database file -- and wall clock time. Just gotta try some values and see what "feels" right -- maybe checkpoint every 10,000 blocks?</div> text/html
https://whatsonchain.com/tx/dfd3475a64703b3a0b11dfea4cfd66f5f02ddebbfc3014f1db82500a5416b85e