<p>Ok so its finally up and working.</p>

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

<pre><code>14:44:48  getinfo

15:36:10
{
"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" : ""
}
</code></pre>

<p>Note the delay of <strong>52 minutes</strong> 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.</p>

<p>I might look into it further so I can log a bug report. </p>

CC BY-SA 3.0
2016-01-31T20:17:18.923Z
2016-01-31T20:17:18.923Z
Linef4ult
<p>I'm having issues with blockchain catchup that I believe to be related to the underlying file system.</p>

<p><strong>Symptoms:</strong> 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. </p>

<p>Last run:</p>

<pre><code>BOOT AT: ~353355
STUCK AT: 359430
</code></pre>

<p>Logs show many of these errors:</p>

<pre><code>2015-11-21 03:39:26 ERROR: AcceptToMemoryPool : nonstandard transaction: non-final
</code></pre>

<p>End of log: </p>

<pre><code>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.
</code></pre>

<p>This seems to happen on my Flexraid disk array(Snapshot RAID) that appears to the OS (2008R2) as a regular NTFS 8TB volume <em>but</em> 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. </p>

<p>Any suggestions for tweaks to allow stable disk IO? </p>

<p>EDIT: Forgot client info</p>

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

<p>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. </p>

CC BY-SA 3.0
2015-11-21T14:59:01.007Z
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
CC BY-SA 3.0
2015-11-21T15:02:33.657Z
@Bitcoin Sorry, forgot to paste that bit, edited in now
Linef4ult
CC BY-SA 3.0
2015-11-21T15:04:06.750Z
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
CC BY-SA 3.0
2015-11-21T15:06:39.113Z
@Bitcoin is the codebase not shared with "Litecoin Core version v0.10.2.2 (64-bit)"
Linef4ult
CC BY-SA 3.0
2015-11-21T15:09:41.973Z
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
CC BY-SA 3.0
2015-11-21T22:28:21.100Z
While I was waiting for something else to finish I decided to drop in a newer BMC firmware. Killed the machine. I'll return to the question later, thanks.
Linef4ult
CC BY-SA 3.0
2016-01-25T13:26:10.297Z
Update: Upgrading QT didn't solve it
Linef4ult
<wallet><blockchain><bitcoin-qt-setup>
Bitcoin-QT issues with non standard filesystem
Linef4ult
# Bitcoin-QT issues with non standard filesystem

(Asked by: username_0 on 2015-11-21)

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.

**Tags:** wallet, blockchain, bitcoin-qt-setup

> **Comments:**
> **username_1**: 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.  
> **username_0**: @Bitcoin Sorry, forgot to paste that bit, edited in now  
> **username_1**: 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.  
> **username_0**: @Bitcoin is the codebase not shared with "Litecoin Core version v0.10.2.2 (64-bit)"  
> **username_1**: 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.  
> **username_0**: While I was waiting for something else to finish I decided to drop in a newer BMC firmware. Killed the machine. I'll return to the question later, thanks.  
> **username_0**: Update: Upgrading QT didn't solve it  

---

## 1 answers

### Answer by username_0 on 2016-01-31. Score: 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

15:36:10
{
"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.


---

