On Sat May 16, 2026 at 3:21 PM EDT, H. Hartzer wrote:
> I wanted to say that as of v0.18.5.0, Monero is running a lot better on
> OpenBSD. I still have to use --db-sync-mode=fast:async:10000 -- if I
> don't, once synced the system is incredibly slow.
>
> I wanted to say this in case anyone had given Monero a try under OpenBSD
> before and found it unusable. It's still not *good*, but it's getting
> better and maybe worth a second chance.
>
> Stopping the daemon does hang the system for about a minute, which is a
> lot better than it used to be!
>
> On Wed Dec 17, 2025 at 10:03 AM UTC, Stuart Henderson wrote:
>> as said before...
>>
>> https://marc.info/?l=openbsd-ports&m=176200894330926&w=2
>>
>> without patching to force writemap, lmdb is *not* going to work on OpenBSD
>
> I still haven't looked into this yet.
While I'd also love to see Monero in the OpenBSD ports tree I still
unfortunately am of the mind that it's still too broken to consider. The
fact that the database can only run in the unsafe mode where any
unexpected stops can irrecoverably corrupt the entire database is pretty
horrid to the end-user.

As noted, The reason this issue occurs is because OpenBSD--unlike
FreeBSD and Linux--lacks a Unified Buffer Cache (ubc). A ubc makes it so
when a program writes to a file using write(), the OS modifies the same
physical memory pages used by mmap.

While neither a kernel, Monero, or LMDB dev, from the research I've done
I've pieced together that there are really only two real solutions to
run Monero "smoothly" on OpenBSD, both of which are not easy:

1. Like Linux/FreeBSD do, the OpenBSD kernel would need a ubc.
2. LMDB would need to be vendored to bridge the split-cache gap manually
   without relying on the OS. Every time a write() call is made, LMDB
   would need to issue an msync(MS_INVALIDATE) on the exact memory pages
   that were modified (though this may just introduce the exact same
   halting overhead).

Andrew