Bitcoin Knots Update -> SSD Daily TBW Skyrockets

[nc50lc]

If increasing system RAM and the bitcoin dbcache value doesn't fix this, perhaps tweaking some of those options will. Let me know if you have any thoughts on that.

Take note that the underlying issue that certain versions of Knots and Core v31.0 trigger that increased disk usage is still unanswered.
And the RAM upgrade is not the direct solution but only to help reducing the disk load as we previously mentioned.

Maybe it's related to this newly posted issue: github.com/bitcoin/bitcoin/issues/35298?
Currently, it has no response.

[ABCbits]

Out of curiosity, is the sync speed noticeably slower (as in total downloaded and verified block) compared with Knots 29.3 or Core 31? You can use debug.log to know the overall sync speed.

I'm not quite sure what I'm looking for in debug.log to determine this. Nothing was jumping out at me when I looked through it, but I don't really know what I'm looking for.

Your debug.log should contain many lines like this. It shows date, time and block height (such as height=0).

Code:

2026-03-01T07:07:28Z UpdateTip: new best=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2009-01-03T18:15:05Z' progress=0.000000 cache=0.3MiB(0txo)

You already have image that show disk write across different node software and version. So you can estimate sync speed by getting 2 lines from 2 different date and time (e.g. first line after you start Knots 28.1 and last line before you stop Knots 28.1). I hope you get the idea.

Edit: as corrected by @LoyceV, my idea wouldn't work as expected for node that already finished initial sync/block download.

[LoyceV]

You already have image that show disk write across different node software and version. So you can estimate sync speed by getting 2 lines from 2 different date and time (e.g. first line after you start Knots 28.1 and last line before you stop Knots 28.1).

I don't think that's going to work: OP's node was already fully synced, so each block was only added when it was found by a miner. Your suggestion would have worked if OP was doing an IBD.

[vxyz123456]

If increasing system RAM and the bitcoin dbcache value doesn't fix this, perhaps tweaking some of those options will. Let me know if you have any thoughts on that.

Take note that the underlying issue that certain versions of Knots and Core v31.0 trigger that increased disk usage is still unanswered.
And the RAM upgrade is not the direct solution but only to help reducing the disk load as we previously mentioned.

Maybe it's related to this newly posted issue: github.com/bitcoin/bitcoin/issues/35298?
Currently, it has no response.

Hi, it's been a day now, and unfortunately increasing the RAM to 16 GB and increasing the dbcache value did nothing. I checked SWAP usage with htop and it's very low. It is consistently showing 640K/4.00G.

Regarding the issue you posted, well, I guess I should have checked this sooner. I just used iotop to get cumulative writes by process

Code:

sudo iotop -oPa

and after letting it sit for 30 minutes I see that bitcoin-qt (Core 31.0) wrote 10.28 GiB and Fulcrum only wrote 260.97 MiB (two new blocks were found in this time window).

This whole time I had assumed the node was interacting with the indexer differently and was causing the indexer to do all the extra writes. It appears that my assumption on that was wrong. So I don't think changing those Fulcrum settings I mentioned earlier will do anything, nor would updating Fulcrum.

I have not added debug=leveldb into my bitcion.conf file yet, so currently I don't see the same output that tuxArg mentioned in the github issue. I will do that next and see how it varies between Core 31.0 and Knots 28.1.

[LoyceV]

Code:

sudo iotop -oPa

and after letting it sit for 30 minutes I see that bitcoin-qt (Core 31.0) wrote 10.28 GiB and Fulcrum only wrote 260.97 MiB (two new blocks were found in this time window).

I'll test this for an hour on my server (Bitcoin Core 29 with Fulcrum) and post back here.
Fulcrum stats:

Code:

    "clients_connected": 222,

Update: It was a bit more than an hour, I think 11 blocks weer found.

Code:

bitcoind: 7.42 GB read, 596.67 MB written
Fulcrum: 1345.41 MB read, 33.09 MB written

This was with 12 GB dbcache and 32 GB RAM.