Full set of .artifacts is 2GB, not 100 :o)
I have not tested it, because I don't have HDD anymore, but block log should not require fast storage - once it is in live mode, it only needs to write couple kilobytes per 3 seconds. Even during replay HDD should be just fine.
One of the features of split block log is the ability to share all but last part. You can have multiple nodes that use the same block log parts and related artifacts symlinked to their .blockchain folders from the same actual storage location. Only the last part that is being written by each node separately needs to be stored locally for each node (but once it is filled and next part file is created, you can copy new filled part to shared location, stop the node, symlink and restart). That way all your nodes can fully participate in p2p syncing and provide block_api functionality while you only have one copy of block log. That feature is useful if you have multiple nodes on servers in the same location (for example for different services, load balancing or witness with bastion node).
Depends on how long it has been running for. Mine is 97G and slowly growing. I believe mine is experiencing a bug, because most of my nodes are ~2GB, but some are growing.
I believe this is what someguy does with his hosted witness node service.
I wonder how does it even work (what is the content of your .artifacts) - valid file contains header (
artifact_file_header) and then one 24 byte record for each block (artifact_file_chunk). If your file is bigger it definitely points to a bug. Your log might already contain some info pointing to source of a problem (look for messages originating fromblock_log_artifacts.cppor any warnings/errors related to block log).I was going to blow the node away since my other nodes it is 2.2GB or so, but this one it just has been growing, but if I can get some information on where this bug is coming from, it would be helpful to resolve it.