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.

Update: I got pulled into something else and had let iotop run the whole time. Over a 6 hour period, bitcoin-qt wrote 62.93G and Fulcrum wrote 3.41G with Core 31.0. I am going to switch to Knots 28.1 and let it sit for a long time to compare. Also, I noticed that the writes were not happening evenly, usually bitcoin-qt would not write much and then the cumulative writes would increase in roughly 10-15G increments over a period of about a minute.

Another update: I let iotop run for 5.5 hours with Knots 28.1 running and I see bitcoin-qt wrote 143.18M and fulcrum wrote 109.16M. I'm surprised fulcrum wrote so much less (maybe I captured some event earlier today in that 6 hour window when running Core that didn't happen while running Knots), but regardless, there's a clear difference in the amount of writes attributable to bitcoin-qt under each node version. Next I'm going to add debug=leveldb to the bitcoin.conf file and see how that differs between the version to see if its related to that github issue.

[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.