No, Garage disables LMDB's safety mechanisms by default. By default, LMDB performs whatever necessary syncs and is 100% crash proof, even in the face of power outages. Garage's problems are of their own making, not because LMDB has unsafe defaults.

mmap/msync gives no hints about which pages are dirty (unless the app tracks them itself and msyncs them individually, which would completely defeat any reduced syscall advantage of using a writable mmap in the first place) so the entire map must be scanned for dirty pages.

In practice, the expected performance advantages of using a writable mmap just aren't there, and coupled with the ease of silent corruption, it's best to never use that approach.

As for what you claim the paper's authors were saying - I quoted their text verbatim. Your interpretation is not what they said.

They claimed using mmap safely is impossible, and using it correctly requires more complexity than a traditional DB design. The safety claim was already disproven by multiple researchers. To prove their second claim they would have had to produce a DB that did traditional buffer management and was simpler and more performant than using mmap. They never did any such thing, nor could they.

Since LMDB manages multiple tables as a tree of trees, no fine tuning is needed. The internal paths to every hot page automatically take priority, regardless of which index or how large each index is. So a simpleminded LRU always makes optimal use of available cache, regardless of access pattern or other load on the system.

No. Monero's tail emission rate was specifically chosen to be less than the rate of global gold production. Do you claim the price of gold is intended to decrease?

A continuous emission like Monero's doesn't equate to inflation/devaluation. It allows its userbase to expand organically, without artificial scarcity pumping its price.

I have no reason to lie, I'm not selling anything. Bitmain is selling mining hardware, take a look at their claims. They've had 7 years to try to crack it.

The random programs change too quickly to just implement them directly on an FPGA. Reprogramming the entire chip like that takes too much time.

Yep. Nothing about computing architecture has changed.

> I would love to show you how easy this is to reproduce, even on fresh installs of Ubuntu and/or MacOS on otherwise-stable hardware (never tried Windows... easier?).

If it's so easy to reproduce, you should be able to screen record a session with two terminal windows:

1 with monerod running and syncing the blockchain

2 send a `kill -9` to the monerod

1b restart monerod

And then we should see the error message you're referring to.

I was talking about database sync, not blockchain sync. You don't need to use safe sync mode if you don't have to worry about machine crashes. And just killing the process will never corrupt the blockchain DB.

> This may be old behavior... I go way back

On this particular point, I go way back further than you.

The post described both modes. The only difference is that Fast mode processes the cache to generate the full 2.1GB dataset, so subsequent programs can just reference it as needed. Light mode uses only the 256MB cache and generates the required dataset values individually, on each access. That saves RAM but costs more CPU time.

In reality, no one has been able to build any device for RandomX that isn't actually a CPU. The closest thing to a "mining ASIC" is just a bunch of RISC-V cores.