Commit graph

10 commits

Author SHA1 Message Date
moneromooo-monero
b750fb27b0
Pruning
The blockchain prunes seven eighths of prunable tx data.
This saves about two thirds of the blockchain size, while
keeping the node useful as a sync source for an eighth
of the blockchain.

No other data is currently pruned.

There are three ways to prune a blockchain:

- run monerod with --prune-blockchain
- run "prune_blockchain" in the monerod console
- run the monero-blockchain-prune utility

The first two will prune in place. Due to how LMDB works, this
will not reduce the blockchain size on disk. Instead, it will
mark parts of the file as free, so that future data will use
that free space, causing the file to not grow until free space
grows scarce.

The third way will create a second database, a pruned copy of
the original one. Since this is a new file, this one will be
smaller than the original one.

Once the database is pruned, it will stay pruned as it syncs.
That is, there is no need to use --prune-blockchain again, etc.
2019-01-22 20:30:51 +00:00
moneromooo-monero
704b60caf0
block_queue: faster check whether a block was requested 2018-07-20 16:05:56 +01:00
moneromooo-monero
ed2c81ed95
replace std::list with std::vector on some hot paths
also use reserve where appropriate
2018-06-26 22:14:21 +01:00
xmr-eric
84a7f6a482 Readd copyright starting date 2018-01-26 10:03:20 -05:00
xmr-eric
18216f19dd Update 2018 copyright 2018-01-26 10:03:20 -05:00
moneromooo-monero
70b8c6d77a
cryptonote_protocol: misc fixes to the new sync algorithm
Fix sync wedge corner case:
It could happen if a connection went into standby mode, while
it was the one which had requested the next span, and that span
was still waiting for the data, and that peer is not on the
main chain. Other peers can then start asking for that data
again and again, but never get it as only that forked peer does.

And various other fixes
2017-08-21 21:57:19 +01:00
moneromooo-monero
7b74760756
cryptonote_protocol: kick idle synchronizing peers
In case they dropped off downloading for any reason, they'll get
sent to download again.
2017-08-16 22:24:50 +01:00
moneromooo-monero
08abb670e1
protocol: fix reorgs while syncing 2017-08-12 11:22:42 +01:00
moneromooo-monero
f57ee382b8
cryptonote_protocol: retry stale spans early
Connections can be dropped by the net_node layer,
unbeknownst to cryptonote_protocol, which would then
not flush any spans scheduled to that connection,
which would cause it to be only downloaded again
once it becomes the next span (possibly after a small
delay if it had been requested less than 5 seconds
ago).
2017-08-07 09:33:17 +01:00
moneromooo-monero
5be43fcdba
cryptonote_protocol_handler: sync speedup
A block queue is now placed between block download and
block processing. Blocks are now requested only from one
peer (unless starved).

Includes a new sync_info coommand.
2017-08-07 09:33:04 +01:00