Bitcoin-QT issues with non standard filesystem

Question

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.

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

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.