3

Monero blockchain is an LMDB. LMDB uses copy-on-write. btrfs with copy-on-write may decrease write performance of LMDB. However, the bottleneck during monero blockchain synchronization seems to be random read instead of write. btrfs without copy-on-write is as unreliable as ext4 or xfs without journal.

I'm considering btrfs, ext4, and xfs. Which one is the best for monero blockchain synchronization on HDD?

Does autodefrag btrfs mount option degrade synchronization performance? Does btrfs compression improve random read performance?

Sync performance is important. Resilience against power loss is considered, too.

  • "Sync performance is important." <- Then use an SSD, that will give far better performance regardless of which filesystem you use. – jtgrassie Feb 12 '21 at 03:57
  • Multi-terabyte SSD is still expensive. I can't afford them. I also haven't seen 5TB SSD on market. So, I chose to optimize monerod on HDD. –  Feb 12 '21 at 05:47
  • 1
    "Multi-terabyte SSD is still expensive" <- A full, unpruned Monero blockchain is <100G. – jtgrassie Feb 12 '21 at 15:59
  • That's a short-sighted perspective. In decades, it will be 6TB and even more. There is no upper limit to monero blockchain size. –  Feb 14 '21 at 03:04
  • A pruned blockchain is ~30G and the growth curve is well below the advances in storage and decreasing costs. Consider how storage has changed over the last "decades". Most average mobile phones have enough SD storage for the Monero blockchain (pruned or unpruned). I digress. You mentioned importance of sync speed so I'd be remiss not to point out that SSD will give you the most measurable increase. – jtgrassie Feb 14 '21 at 06:48
  • @crocket did you ever figure out which btrfs config options are optimal for monero's LMDB? I'd also like to use btrfs because snapshots are a requirement since a corrupted DB (it happens) means waiting another ~4 weeks to download the blockchain from 0 -- unless I can restore from a snapshot – Michael Altfield Jun 25 '22 at 08:50

1 Answers1

1

http://www.lmdb.tech/bench/microbench/july/ provides some great research regarding different filesystem format performance on LMDB sytems.

"Just to summarize, jfs with an external journal is the fastest for synchronous writes. If your workload demands fully synchronous transactions, this is clearly the best choice. Otherwise, the original ext2 filesystem is fastest for asynchronous writes. "

Question becomes does your instance of monerod require synchronous transactions or just asynchronous writes?. The Symas Corp. research highlights the considerable throughput cost of journaling file systems. Given that the blockchain is a public ledger I do not see the value in journaling the alterations to your copy of the public file. So mkfs.jfs if you must but ext2 seems like the better approach to me. And no, I would never select ext4. But please review the Symas literature on your own http://www.lmdb.tech/bench/microbench/july/

DGRpost
  • 11
  • 1
  • I'm confused. The word "LMDB" doesn't appear once on that Database Microbench test's results. Or is it the case that LevelDB, SQLite, Kyoto TreeDB, OpenLDAP MDB, and BerkelyDB all use LMDB? – Michael Altfield Jun 25 '22 at 08:46