This issue has come up in the forums a couple of times, without an exact pinpoint of the cause, but no real solution was ever provided/cause found. Trying it here with a more extensive analysis. I am experienced in Linux, and am debugging this machine for a friend. I have had it in my home lab now for a couple of days, with ssh access.
His problem description and my remote assistance was the same (slow sync after about 70%). After taking the machine in, I re-installed Start9 on the HP Elitedesk G2 800 with 8 GB RAM, and a TB brand-new 2TB SSD. After enabling Bitcoin (transaction index off, txindex=0) within less than 24h I get to 70% syncing, around block 810000, after that syncing speed massively drops.
Around 25% syncing I had a syncing speed of 1% per 20-30 minutes - now at syncing progress of 70% we are talking less than 0.1% per hour.
I have myself a bitcoin node running in my homelab on an old and weaker laptop from 2014, syncing did not took nearly as long nor did it slow down. The syncing speed is definitely not normal. I added my local bitcoin node manually via the config to the Start9 Bitcoin config to speedup block download and rule out slow internet connection speeds. I verified my local bitcoin node has an incoming (non-routable) connection from the Start9 node.
During the slow sync, the host system shows no sign of oversubscription. htop reports Mem usage of less than 1GB out of 8GB, the 4 CPU cores are all hanging around 50% utilization tops.
Iām tracking syncing progress using ājournalctl -fā, here is some example output:
Sep 28 15:26:11 musty-girdle bitcoind.embassy[508100]: 2025-09-28T15:26:11Z UpdateTip: new best=0000000000000000000485993e37cd61641cbba93a61793301bff095728b02ff height=811584 version=0x20000000 log2_work=94.468610 tx=904690973 date='2023-10-10T19:58:24Z' progress=0.726480 cache=578.8MiB(4561877txo)
There is steady progress in the journalctl, without any other outputs (except for some health-check podman spawns).
I even increased the dbcache in the Bitcoin config to 4096M, but no noticeable difference. I navigated to the bitcoin data dir at /embassy-data/package-data/volumes/bitcoind/data/main and check the debug.log file - again nothing suspicious.
Now, I am not a docker/podman expert, but from my research (with the Help of AI and some manual source verification) my suspicion is that this is due to the overlayfs configuration in podman/start9.
From the ouput of āpodman infoā and āpodman inspect ā it becomes apparent that the container uses an overlay backed by btfrs, instead of a volume mount. This is also confirmed by using āmountā, which shows the overlay for the container mounted as type overlay:
overlay on /var/lib/containers/storage/overlay/b160dcd534a8affe1e5b57ca559c7d118f1dc41bc6d4854a57c118e943c68afd/merged type overlay
Upon running:
podman info -f '{{index .Store.GraphStatus "Native Overlay Diff"}}'
I get āfalseā, which means the overlayfs doesnāt use native diffing, and in combination with btrfs podman falls back to using fuse-overlayfs. Performance issues with fuse-overlayfs are widely known and described, especially for larger filesytems. Given that the bitcoin container grows beyond 500GB+, this is mostlikely the case why the syncing gets slower, and slower over time.
This suspicion is also backed up by the fact that the dashboard monitor shows more than 30% utlization (out of 37% total) comes from kernel space. This is very odd as Bitcoin runs in userspace - another pointer that it is the container/overlay abstraction in kernel-space causing the issue (not just bitcoin block validation being slow, which would happen in user space). The screenshot:
Anybody can confirm this? Any ideas? I wonder why noone has brought this up before, since the very same observation of slow syncing has been reported a couple of times. But if my hunch is correct, this is a design flaw of the bitcoin container in start9.