Is this normal?
Unsure what the normal sync rate currently is with that hardware setup, but it wouldn't surprise me, particularly with a block of that size. (Someone who's run a sync recently can add more details or add a correction.) If you look at block 9280706 on Etherscan, you'll see it contains 188 transactions, 103 internal transactions, and is 99.88% full.
When you import a block, you're also importing all of the state changes associated with the transactions inside that block. Applying those state changes to the overall state you've synced so far is what's taking a majority of the time.
From Peter, one of the main Geth devs:
"To truly have a synchronized node, you need to download all the account data, as well as all the tiny cryptographic proofs to verify that no one in the network is trying to cheat you. This itself is already a crazy number of data items. The part where it gets even messier is that this data is constantly morphing: at every block (15s), about 1000 nodes are deleted from this trie and about 2000 new ones are added. This means your node needs to synchronize a dataset that is changing 200 times per second. The worst part is that while you are synchronizing, the network is moving forward, and state that you begun to download might disappear while you're downloading, ..."
Also, does anyone know where I can find what each term of the log means?
blocks
- The number of blocks imported.
txs
- The number of transactions being imported. (We're importing a full block here; 9280706 contains 188 transactions.)
mgas
- Million gas. Those 188 transactions use 9,978,0779,978,077 gas.
elapsed
- The time taken to download the block. This doesn't include the time taken to apply the state changes, which you've seen takes much longer.
mgasps
- Million gas per second. We imported 9.978 Mgas of work in 2.180 seconds.
number
- The block number.
hash
- The hash of the block header.
dirty
- This is less intuitive. It's a measure of the amount of state change (disk I/O) associated with the imported data. So importing this block will result in rewriting 662 MB of data.