I'm having issues with blockchain catchup that I believe to be related to the underlying file system.

Symptoms: Significantly behind the network, start client and begin catchup. Catchup proceeds for 1-2GB then halts. CPU usage is 0 for the process, but it holds 500MB-1GB RAM allocated. 0 connections. Console commands receive no response, so crashed process? If I restart the client it will proceed again for a similar length of time, then repeat the behaviour.

Last run:

BOOT AT: ~353355
STUCK AT: 359430

Logs show many of these errors:

2015-11-21 03:39:26 ERROR: AcceptToMemoryPool : nonstandard transaction: non-final

End of log:

2015-11-21 04:03:10 UpdateTip: new best=0000000000000000041ca40bdec7946dc4105fea0cefb26ea7fb8914880fe089  height=359623  log2_work=82.893042  tx=71115044  date=2015-06-06 04:15:15 progress=0.806010
2015-11-21 04:03:14 UpdateTip: new best=0000000000000000028104e61aabd1b31bd0a136c33daecdd92165126aeb7ce1  height=359624  log2_work=82.893074  tx=71115578  date=2015-06-06 04:29:37 progress=0.806021
2015-11-21 04:03:15 UpdateTip: new best=00000000000000000b0c4437cd594ae56bb6dc532c497af9b595b653311345f5  height=359625  log2_work=82.893107  tx=71115639  date=2015-06-06 04:26:21 progress=0.806019
2015-11-21 04:03:26 Pre-allocating up to position 0xd00000 in rev00278.dat
2015-11-21 04:11:27 UPnP Port Mapping successful.
2015-11-21 04:31:27 UPnP Port Mapping successful.
2015-11-21 04:51:27 UPnP Port Mapping successful.
2015-11-21 05:07:26 socket inactivity timeout
2015-11-21 05:09:30 socket inactivity timeout
2015-11-21 05:11:27 UPnP Port Mapping successful.
2015-11-21 05:31:27 UPnP Port Mapping successful.
2015-11-21 05:51:27 UPnP Port Mapping successful.
2015-11-21 06:11:27 UPnP Port Mapping successful.
2015-11-21 06:31:27 UPnP Port Mapping successful.
2015-11-21 06:51:27 UPnP Port Mapping successful.
2015-11-21 07:11:27 UPnP Port Mapping successful.
2015-11-21 07:31:27 UPnP Port Mapping successful.
2015-11-21 07:51:27 UPnP Port Mapping successful.
2015-11-21 08:11:27 UPnP Port Mapping successful.
2015-11-21 08:31:27 UPnP Port Mapping successful.
2015-11-21 08:51:28 UPnP Port Mapping successful.
2015-11-21 09:11:28 UPnP Port Mapping successful.
2015-11-21 09:31:28 UPnP Port Mapping successful.

This seems to happen on my Flexraid disk array(Snapshot RAID) that appears to the OS (2008R2) as a regular NTFS 8TB volume but not on a regular 160GB backup drive. I've seen issues once before when an application attempted to create many files at once, this was resolve by tweaking that applications write caching.

Any suggestions for tweaks to allow stable disk IO?

EDIT: Forgot client info

"version" : 90300, v0.9.3.0-g40d2041-beta
"protocolversion" : 70002,
"walletversion" : 60000,
"balance" : 2.27391276,
"blocks" : 353567,
"timeoffset" : 9,
"connections" : 8,

NB: Client is out of date BUT I've tested with the latest LTC-QT and have the same RAID no single yes behaviour so its unlikely the cause.

  • What version are you running? That's almost certainly not the latest. The AcceptToMempool error isn't an error that's anything to do with anything, you can ignore that.
    – Claris
    Nov 21, 2015 at 14:59
  • @Bitcoin Sorry, forgot to paste that bit, edited in now
    – Linef4ult
    Nov 21, 2015 at 15:02
  • Woo that's super old, you're 2 major versions behind, almost 3! Update your version of Bitcoin Core to 0.11.2, there's been massive changes in the sync process since 0.9.3. If nothing else it will be significantly faster, and there's been some changes to the way things are written to disk which might fix your problem.
    – Claris
    Nov 21, 2015 at 15:04
  • @Bitcoin is the codebase not shared with "Litecoin Core version v0.10.2.2 (64-bit)"
    – Linef4ult
    Nov 21, 2015 at 15:06
  • There's big changes from 0.10 to 0.11 though, and Litecoins network is significantly less intensive to process (there's almost no transaction volume). There's security fixes you need to catch up on as well, there's no reason for anybody to use 0.9 era Bitcoin today.
    – Claris
    Nov 21, 2015 at 15:09

1 Answer 1


Ok so its finally up and working.

With v0.9.3.0-g40d2041-beta the core process definitely crashes on that volume. Now with version : 110200 it appears as if its crashed, but doesn't. Setting the write catch to 512MB may have had an impact here.

14:44:48  getinfo

"version" : 110200,
"protocolversion" : 70002,
"walletversion" : 60000,
"balance" : xyz,
"blocks" : 388767,
"timeoffset" : -7,
"connections" : 1,
"proxy" : "",
"difficulty" : 79102380900.22598300,
"testnet" : false,
"keypoololdest" : 1385606583,
"keypoolsize" : 101,
"unlocked_until" : 0,
"paytxfee" : 0.00000000,
"relayfee" : 0.00005000,
"errors" : ""

Note the delay of 52 minutes for a console command to return a response. This probably indicates bad threading that an IO process can block the interactive terminal. Eventually though block processing does resume and it caught up 16GB worth of data.

I might look into it further so I can log a bug report.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.