Timeline for Initial sync taking well over half a week
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 8, 2017 at 17:11 | comment | added | Arman | SSD did the trick. I redid it on my linux machine with SSD geth --fast --cache=2048 --datadir=/my/custom/path at 1pm today and it was done by 6pm. Now can I copy the chaindata from that machine to another and run the app? | |
| Jul 7, 2017 at 14:51 | comment | added | Arman | Then something must have gone wrong with my initial run since that only took 1-2 days and there were no interruptions. | |
| Jul 7, 2017 at 13:58 | comment | added | xgabrielx | Correct, only one download is normal. | |
| Jul 7, 2017 at 13:12 | comment | added | Arman | I only ran --fast, by that logic the second sync should not take place right? So it should download the blockchain and finish? But this started from the beginning when it reached the top once. | |
| Jul 7, 2017 at 12:32 | comment | added | xgabrielx | I can't in detail explain the difference between fast and normal sync. It has to do with verification of the blocks (in normal mode you actually execute each transaction). | |
| Jul 7, 2017 at 11:58 | comment | added | Arman | I did remove the entire blockchain, and to be safe, I actually used a different --datadir when I ran with --fast. The process wasn't stopped until today. Can you tell me what the second sync process does as opposed to first (it runs from 0 to latest block number twice) | |
| Jul 7, 2017 at 11:33 | history | answered | xgabrielx | CC BY-SA 3.0 |