Topic: Splitting Drives for Core and Armory (Read 209 times)

Personally, I would just restore the Armory wallets from your paper backups... rather than copying old wallet files etc.

There is always the (small) possibility that the old files are corrupt and/or may not play nicely with the latest version of everything. Restoring from the paper backups should make that possibility zero

Was just concerned that any discrepancy or mistake in bat file might mess things up. 

Anyway after about 36 hours bcc downloaded so I reinstalled and started armory and it came up and synced. 

next step is to restore old armory wallets..   is it best to use the electronic backups or just shutdown all put wallets in place and restart?

Thanks so much for all your help HCP and goatpig and for all those that responded to the disk size poll!

No more than 20GB.


I'm not sure I understand the question. You talking about config files?

Thanks, goatpig.

from previous recommendations, i've decided to back up and reinstall and reload everything.

from what you mention, it seems like the core files should fit on my C drive with 435 GB free space.

about how large should i expect the files in ...AppData\Roaming\Armory to be?  I'm wondering if i'll be able to keep it all on C, or if i should plan from the start to split it across drives.

one last question - is there any risk (chance of not working again, etc) with using batch files to invoke bitcoin-qt.exe with a datadir parameter, and ArmoryQt.exe with satoshi-datadir and dbdir parameters?

Core.bat contents:

Armory.bat contents:


Thanks again for everyone's support on this!

/blocks: 278 GB
/chainstate: 4.15 GB


Core saves the chain in datadir. Assuming your system is in C: and your user name is RAM103, it would default to:


Armory saves its db in dbdir/databases. If you do not specify a custom dbdir, dbdir will be datadir. datadir carries the wallets and settings. It would default to:

Each of the blocks is around 133 MB, so it does seem likely there is some corruption going on.

Frankly, at this point i am willing to try (almost) anything...

i was quite active with bc 3 -4 years ago, and had a block chain backup on an external ssd; this is what is started with, so there very well could be some forward compatibility issues.
the latest status:  after running for about 36 hours, i woke this morning to find Win10 had rebooted on me (...

tonight i intend to restart again - may seriously consider backing up and wiping bc and armory directories and restarting.   

any ideas on how big bc core / blocks and chainstate total storage required is?   i have a bit over 400 GB free on my C drive or i have the external 1 TB SSD that is about 10x slower... i would love to keep it all on the C drive if i could, but got a warning i was almost out of disk space when starting bc core for the first time in a few years.

This was what was behind me trying to split with \bitcoin\blocks and chainstate on the slower drive and Armory on C


is there a good summary on the web of which directories / files that btcore and armory create & access?   I've tried to use MS Windows Process Monitor to detect if one of the programs is hung up, but need to know directories & files to look at.

Block files aren't necessarely 128MB, some earlier files can be as large as 1-2GB.

That "anomoly" is perfectly normal...

I am however still a little confused as to the number of block files that your node has... a quick very non-scientific survey of other full node users indicates that other nodes seem to be around the same 1975ish "blk.dat" file count as my node.

So, I'm wondering if there is some sort of weird issue with your Bitcoin Core install and/or data files that could be causing issues with ArmoryDB? Which then leads to a "need to redownload the blockchain" solution

If you have the time (and disk space)... perhaps you could try shutting down Bitcoin Core (and Armory), backing up your current "blocks" and "chainstate" dirs from the Bitcoin Core datadir and then deleting the contents of "blocks" and "chainstate" (once you've backed them up of course!) and then restarting Bitcoin Core and letting it sync from scratch.

I'm honestly not sure what else to try at this point

I'm not sure about whether i have transaction indexing turned on or not; i believe i'm using the default settings other than the -data_dir param in

"C:\Program Files\Bitcoin\bitcoin-qt.exe" -datadir="F:\Bitcoin"

 and the two directory options in the Armory invocation:

"C:\Program Files (x86)\Armory\ArmoryQt.exe" --satoshi-datadir="F:\BitCoin" --dbdir="C:\BitCoin\Armory"


Following your suggestion, I shutdown and powered off PC.

Restarted last night at 1:00 AM. 

F:\bitcoin\blocks seems up to date; latest activity at 8:04PM, 6 minutes ago on BLK02752.dat.  Total size of blocks dir is 420 GB.

Armory GUI has 'Node Status' all green, and has had flashing green status bar following the caption 'Organizing Blockchain' for multiple hours (16 hours).  Most recent file activity in C:\bitcoin directory is in the Armory subdirectory - the file txfilters was last written at 2:56 AM, about 2 hours after restart.

is this all normal?  should i see file updates / progress anywhere?

dbLog.txt last written to at 4:07 AM; only anomoly at 4:05:10.328 below..  remainder looks ok?

-INFO  - 04:04:44.469: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2704
-INFO  - 04:04:50.031: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2707
-INFO  - 04:05:00.062: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2708
-INFO  - 04:05:06.734: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2711
-INFO  - 04:05:10.328: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:493) Found next block after skipping 451950bytes
-INFO  - 04:05:16.000: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2712
-INFO  - 04:05:22.859: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2715
-INFO  - 04:05:32.719: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2716
-INFO  - 04:05:38.922: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2719
-INFO  - 04:05:47.562: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2720
-INFO  - 04:05:54.797: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2723
-INFO  - 04:06:03.422: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2724
-INFO  - 04:06:09.547: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2727
-INFO  - 04:06:19.266: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2728
-INFO  - 04:06:25.437: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2731
-INFO  - 04:06:35.141: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2732
-INFO  - 04:06:41.125: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2735
-INFO  - 04:06:51.828: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2736
-INFO  - 04:06:57.000: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2739
-INFO  - 04:07:06.406: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2740
-INFO  - 04:07:13.641: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2743
-INFO  - 04:07:22.172: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2744
-INFO  - 04:07:28.219: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2747
-INFO  - 04:07:36.219: (e:\users\goat\code\armory3\cppforswig\databasebuilder.cpp:281) parsed block file #2751
-INFO  - 04:07:45.172: (e:\users\goat\code\armory3\cppforswig\blockchain.cpp:248) Organizing chain

How strange... I don't have another node to compare with, so I can't say for certain if it is a problem or not... but I wouldn't think that was likely to be an issue. It'll just be the amount of info the node is storing in block files... do you have transaction indexing turned on perchance?

Did you get a chance to restart everything? Is the DB working OK?

also... you should also see new blocks showing in armorylog.txt if it's working OK

But that will only happen once all the initial scanning has finished.

i just checked the F:\bitcoin\blocks directory; there are 2752 BLK*.dat; the highest block number is BLK02751.dat.  Each file is about 133 MB except the last one, which is about 55 MB.   There are also 2752 files with REV*.dat, the highest is REV02751.dat

In Armory-Qt terms:

"dbdir" is where Armory will put it's custom databases
"datadir" is where Armory will look for/store settings and .conf files etc.

Have you read the Armory "pathing" documentation? It explains it all a lot better than I can.


As for the timeout, it's not a "deliberate" thing... more just the DB process "dies" silently   Theoretically, if Bitcoin Core is running and syncing and ArmoryDB is working "properly", it should reflect in dbLog.txt when new blocks arrive and are then processed by ArmoryDB...

Thanks for the response.  I'll check for the block numbers when i get home and repost.

Is --dbdir the correct option to be using, or should i be using --datadir ?

is there an overall timeout for Armory to complete the initial sync?

Should there always be information being added to armoryLog.txt and dbLog.txt?   Is there any other indication that something is locked up / going wrong?   the little 'hour-glass-wheel' on the armory gui initially spins and the bar flashes indicating progress, but after several hours, the screen stops refreshing.  i believe the armory gui is still alive at that point, as i was able to navigate the menu's, and selected 'rescan', which ended up being written into the armory config file for the restart.

Nothing looks obviously wrong with those logs... My guess is that it is just the ArmoryDB process taking so long to do the initial sync that it times out and stops responding?

Although, having said that, one thing that looked out of place to me:

#2748 seems like a large number of block files... currently, my Bitcoin Core node only has #1971 (each file is around 130megs)

If you look in your "F:\BitCoin\Blocks" folder... what is the highest numbered file? should be named something like: "blk0xxxx.dat"

Anyway, I'd recommend NOT doing rescans and such if possible. As that will just make it sit for hours rescanning all the blocks again. At this point, I'd recommend that you simply shut everything down and restart the PC (to ensure any zombie processes are killed). Once you've restarted, then run Bitcoin Core and wait until it is fully synced, then start Armory.

Thanks for the reply.

armorylog.txt:

https://pastebin.com/embed/3SS8TuUa



dbLog.txt:
https://pastebin.com/Zu3tgy8T

Without your logs it will be a bit difficult to troubleshoot.
Log Files will be in your %AppData%/Armory directory (something like C:\Users\YOURPCUSERNAME\AppData\Roaming\Armory) NOTE: Click here if you can't see the "AppData" directory

You will find "armorylog.txt" and "dbLog.txt"

Open them with Notepad and Copy/paste the contents of those files to https://pastebin.com/ and click the "Create New Paste" button... then copy/paste the unique URL that pastebin generates into a post here. If you get a warning that the paste is too big, just copy the bottom half of each file.

Also, it would be useful if you create separate "pastes" for each logfile

I have a windows 10 pc with about 439 GB free on it, and an external SDD with about 900 GB on it (drive F:)

I have installed Bitcoin core 0.19.0.1 and Armory 0.96.5-beta on the C: drive

I have successfully gotten the bitcoin core to load and sync to the external SDD using a batch file with the following contents:

"C:\Program Files\Bitcoin\bitcoin-qt.exe" -datadir="F:\Bitcoin"

I then run ArmoryQt from a batch file with the following contents:

"C:\Program Files (x86)\Armory\ArmoryQt.exe" --satoshi-datadir="F:\BitCoin" --dbdir="C:\BitCoin\Armory"


After running for about three hours running, logging messages like the following:
     
       2020-02-16 15:15:10 (INFO) -- ArmoryQt.py:4672 - Dashboard switched to "Scanning" mode

Armory appears to lock; after 6 more hours, i used the Armory GUI to force rescan, and then restarted... results the same - the system runs for several hours, issuing the message above to the log file, armory locks (still no additional log messages after 24 hours)

My questions:  should the above batch files work correctly, or should i be using the --datadir parameter to specify the C: drive directory for Armory?  Is the syntax of the above correct for windows batch files?

If the above are ok, what else should i try?

i can post log files, but am uncertain how to do that?

Thanks for any and all help!