What is the upper bound of "imported new state entries"?

[sonulrk]

System information

Geth version: 1.6.5 OS & Version: Windows 7 x64 geth Command: geth --fast --cache 8192

Expected behaviour

Geth should start in full mode.

Actual behaviour

After nearing the current block geth is continuously "imported new state entries".

Steps to reproduce the behaviour

Currently running since 10 days.

Geth console info

eth.blockNumber 6 eth.syncing { currentBlock: 3890742, highestBlock: 3890893, knownStates: 17124512, pulledStates: 17105895, startingBlock: 3890340 }

Backtrace

INFO [06-18|10:10:31] Imported new state entries count=384 elapsed=22.001ms processed=17118951 pending=24263 INFO [06-18|10:10:32] Imported new state entries count=384 elapsed=33.001ms processed=17119335 pending=23819 INFO [06-18|10:10:33] Imported new state entries count=384 elapsed=111.006ms processed=17119719 pending=23875 INFO [06-18|10:10:34] Imported new state entries count=384 elapsed=131.007ms processed=17120103 pending=23855 INFO [06-18|10:10:35] Imported new state entries count=384 elapsed=116.006ms processed=17120487 pending=23978 INFO [06-18|10:10:36] Imported new state entries count=384 elapsed=134.007ms processed=17120871 pending=24186 INFO [06-18|10:10:38] Imported new state entries count=384 elapsed=305.017ms processed=17121255 pending=27727 INFO [06-18|10:10:42] Imported new state entries count=384 elapsed=448.025ms processed=17121639 pending=33614 INFO [06-18|10:10:46] Imported new state entries count=384 elapsed=441.025ms processed=17122023 pending=39642 INFO [06-18|10:10:48] Imported new state entries count=384 elapsed=44.002ms processed=17122407 pending=39170 INFO [06-18|10:10:52] Imported new state entries count=384 elapsed=427.024ms processed=17122791 pending=45142 INFO [06-18|10:10:55] Imported new state entries count=384 elapsed=473.027ms processed=17123175 pending=51166 INFO [06-18|10:10:58] Imported new state entries count=384 elapsed=448.025ms processed=17123559 pending=57128 INFO [06-18|10:11:01] Imported new state entries count=384 elapsed=444.025ms processed=17123943 pending=63129 INFO [06-18|10:11:04] Imported new state entries count=384 elapsed=441.025ms processed=17124327 pending=69173 INFO [06-18|10:11:04] Imported new state entries count=1 elapsed=0s processed=17124328 pending=69172 INFO [06-18|10:11:07] Imported new state entries count=384 elapsed=442.025ms processed=17124712 pending=75182 INFO [06-18|10:11:10] Imported new state entries count=384 elapsed=470.026ms processed=17125096 pending=81186 INFO [06-18|10:11:11] Imported new state entries count=384 elapsed=335.019ms processed=17125480 pending=81736 INFO [06-18|10:11:14] Imported new state entries count=384 elapsed=440.025ms processed=17125864 pending=87718 INFO [06-18|10:11:15] Imported new state entries count=384 elapsed=140.008ms processed=17126248 pending=87812 INFO [06-18|10:11:16] Imported new state entries count=384 elapsed=31.001ms processed=17126632 pending=87226 INFO [06-18|10:11:18] Imported new state entries count=384 elapsed=88.005ms processed=17127016 pending=87040 INFO [06-18|10:11:19] Imported new state entries count=384 elapsed=39.002ms processed=17127400 pending=86803 INFO [06-18|10:11:20] Imported new state entries count=384 elapsed=36.002ms processed=17127784 pending=86585 INFO [06-18|10:11:23] Imported new state entries count=1 elapsed=0s processed=17127785 pending=86272 INFO [06-18|10:11:23] Imported new state entries count=384 elapsed=1.610s processed=17128169 pending=86271 INFO [06-18|10:11:25] Imported new state entries count=384 elapsed=143.008ms processed=17128553 pending=87792 INFO [06-18|10:11:28] Imported new state entries count=384 elapsed=183.010ms processed=17128937 pending=90117 INFO [06-18|10:11:28] Imported new state entries count=1 elapsed=1ms processed=17128938 pending=90120 INFO [06-18|10:11:28] Imported new state entries count=1 elapsed=0s processed=17128939 pending=90118 INFO [06-18|10:11:29] Imported new state entries count=384 elapsed=102.005ms processed=17129323 pending=90022 INFO [06-18|10:11:30] Imported new state entries count=384 elapsed=184.010ms processed=17129707 pending=92320 INFO [06-18|10:11:32] Imported new state entries count=384 elapsed=185.010ms processed=17130091 pending=94665 INFO [06-18|10:11:34] Imported new state entries count=384 elapsed=187.010ms processed=17130475 pending=97053 INFO [06-18|10:11:36] Imported new state entries count=384 elapsed=194.011ms processed=17130859 pending=99550 INFO [06-18|10:11:38] Imported new state entries count=384 elapsed=183.010ms processed=17131243 pending=101954 INFO [06-18|10:11:40] Imported new state entries count=384 elapsed=202.011ms processed=17131627 pending=104395 INFO [06-18|10:11:42] Imported new state entries count=384 elapsed=196.011ms processed=17132011 pending=106904 INFO [06-18|10:11:44] Imported new state entries count=384 elapsed=186.010ms processed=17132395 pending=109176 INFO [06-18|10:11:47] Imported new state entries count=384 elapsed=184.010ms processed=17132779 pending=111554 INFO [06-18|10:11:47] Imported new state entries count=2 elapsed=184.010ms processed=17132781 pending=111554 INFO [06-18|10:11:48] Imported new state entries count=384 elapsed=34.002ms processed=17133165 pending=110760 INFO [06-18|10:11:50] Imported new state entries count=384 elapsed=193.011ms processed=17133549 pending=113172

[ghost]

Yes .. same exact effect Command is: geth --syncmode=fast --cache=4096 console

[fjl]

Please try geth v1.6.6.

[n0-m4d]

in my case v1.6.6 does not fix it

[pebwindkraft]

same here, described detailed status here: https://github.com/ethereum/go-ethereum/issues/14571

[yahortsaryk]

The same for me for --testnet (ropsten) on Mac OS. The geth version is 1.6.6. I'm running: geth --testnet --syncmode "fast" --rpc --rpcapi db,eth,net,web3,personal --cache=1024 --rpcport 8545 --rpcaddr 127.0.0.1 --rpccorsdomain "*" --bootnodes "enode://20c9ad97c081d63397d7b685a412227a40e23c8bdc6688c6f37e97cfbc22d2b4d1db1510d8f61e6a8866ad7f0e17c02b14182d37ea7c3c8b9c2683aeb6b733a1@52.169.14.227:30303,enode://6ce05930c72abc632c58e2e4324f7c7ea478cec0ed4fa2528982cf34483094e9cbc9216e7aa349691242576d552a2a56aaeae426c5303ded677ce455ba1acd9d@13.84.180.240:30303" and when it comes near to latest blocks (at https://ropsten.etherscan.io/) it continuously "imports new state entries". If I restart the cmd above it fetches most recent blocks but never reach latest ones.

[porfavorite]

same here... the geth is 1.6.6, running geth --testnet --fast --cache=1024

[adhicl]

I am in same state after a week using geth --fast --cache=1024. Anyone knows what should I do right now?

[thecopy]

Same situation on testnet. OSX, geth 1.6.7-stable-ab5646c5. Started with --fast and --cache 1500

[sonulrk]

What I could understand from this geth fast mode problem is that:

1. You must use Quad core processor with 4 gb or more RAM
2. You must use SSD instead of HDD
3. Your internet connection must be at least 2mbps or more and reliable. If all above are checked then you should try geth. Using geth in full mode you would most probably synced in a week or two max. In fast mode it depends on your luck but you are most probably synced in 2-3 days or never.

[clowestab]

Encountering similar issues. Geth --fast sync does not sync, let alone fast.

Using 1.6.7-stable on Ubuntu, and it gets within 100 blocks and then endlessly imports state entries.

[alfkors]

@clowestab did you ever get it to sync?

[hlagagoalga]

Having same issue. Also using ubuntu, and geth endlessly syncs.

[mboehler]

I am having the same issue. Has anyone been able to solve this problem?

[brennino]

Same problem here, I run geth with 1024 cache and fast syncing three days ago and, after reaching the last block number one day ago, it had never stopped the "Imported new state entries" state.

During this "state entries" phase, however, my balance changed from 0 to the correct value and the block number reported changed from 0 to the a number near the highestBlock value.

This is geth version on my ubuntu machine:

Geth Version: 1.6.7-stable Git Commit: ab5646c532292b51e319f290afccf6a44f874372 Architecture: amd64 Protocol Versions: [63 62] Network Id: 1 Go Version: go1.8.1 Operating System: linux GOPATH= GOROOT=/usr/lib/go-1.8

and this is the result now every half second: ... INFO [09-08|10:05:34] Imported new state entries count=11 flushed=7 elapsed=216.807ms processed=25170515 pending=1852 retry=1 duplicate=5293 unexpected=6261 INFO [09-08|10:05:34] Imported new state entries count=2 flushed=5 elapsed=521.989µs processed=25170517 pending=1847 retry=0 duplicate=5293 unexpected=6261 INFO [09-08|10:05:34] Imported new state entries count=7 flushed=1 elapsed=263.738ms processed=25170524 pending=1862 retry=2 duplicate=5293 unexpected=6261 INFO [09-08|10:05:34] Imported new state entries count=2 flushed=4 elapsed=6.934ms processed=25170526 pending=1859 retry=0 duplicate=5293 unexpected=6261 INFO [09-08|10:05:34] Imported new state entries count=1 flushed=0 elapsed=27.828ms processed=25170527 pending=1861 retry=1 duplicate=5293 unexpected=6261 INFO [09-08|10:05:34] Imported new state entries count=5 flushed=5 elapsed=19.440ms processed=25170532 pending=1860 retry=0 duplicate=5293 unexpected=6261 ...

this is the result of eth.syncing and other geth tools:

eth.syncing { currentBlock: 4249131, highestBlock: 4250814, knownStates: 25172364, pulledStates: 25170517, startingBlock: 0 }

net.peerCount 25

eth.blockNumber 4244762

The ether balance of my wallet is not 0 and is reported correcly and updated to the last transaction made one day ago.

How long is this state supposed to last?

[brennino]

Another information, my .ethereum folder size is currently 41 GB, maybe a little too large for a right fast sync.

[sonulrk]

I think never.

[brennino]

UPDATE: I stopped geth with CTRL-D and reopen it. Now it seems that the "Imported new state entries" phase halted and geth is working correctly updating only new blocks. It seems that the problem is that fast sync continue forever to download states and is not aware that the blockchain has already in a right, consistent state.

So, for now until the issue is solved this is my advise:

• Start geth fast sync
• wait until the command eth.syncing report a currentBlock near the highestBlock
• After that, every few hours run the command: eth.blockNumber ... firstly it returns probably 0 but continue to wait.
• When eth.blockNumber returns a value different from 0 and near the currentBlock value close geth with (CTRL-D or with the command "exit" so it can close correclty and under control) and wait until the program closes in the right way and your operating system shell comes back
• Reopen geth with fast option. You will see the warning "Blockchain not empty, fast sync disabled"... this is the correct behavior, is telling you that fast sync has been finished.
• Now the "Imported new state entries" messages disappear and you just see this messages every few seconds: INFO [09-08|21:12:06] Imported new chain segment blocks=1 txs=131 mgas=5.379 elapsed=13.855s mgasps=0.388 number=4251422 hash=697652…d85ce8

Now your problem has been solved and probably geth avoid to download a lot of states, reducing the hard disk space taken by geth too.

This is valid until the issue will be solved and geth will become aware when the blockchain is correctly synced.

This is my experience, maybe work, maybe not. For me it worked. Hope this helps, Marco

[sonulrk]

Congrats but I had run it for more than 8 hours and eth.blockNumber had shown 6 always. I have to change to parity to sync the blockchain. Edit: Fast sync worked at first run only on consecutive run you have to run in full mode or geth automatically give warning "Blockchain not empty, fast sync disable" and continue with full mode.

[brennino]

I think you have just to wait until eth.blockNumber shows a number near currentBlock before close it and start it again. I forget to tell to remove old blockchains before starting the task I told before. Yes, fast sync can be used with an empty blockchain and only the first time. The command for clear the whole blockchain is "geth removedb" on the operating system shell, it removes everything has been downloaded before. After that you are able to start a fast sync again from an empty blockchain and follow the procedure I told in my prev post hoping it works.

I'm not a geth developer, I just use it so I can't solve the problem or tell you what it does internally or why the command returns you "6" and what you have to do, but it seems that it downloads a lot of states and, when it finds the head state it's able to build the full blockchain. For me this happened when geth.syncing showed a "knownStates" near : 20.000.000 but it can happen before or after.

During my test, after fast sync finished to download all the blocks headers, it takes more than 24 hours more for having eth.blockNumber = 4244762 . I run geth on a server in with a band of 100 Mb/s.

When it showed to me "0" I let it doing the work and after 24 hours I see the command returns 4244762. I haven't tried to run the command in the middle so I don't know if the command returns other numbers before reaching the last block.

I have never used parity but is seems good and use less disk space than geth so it worth a try. Maybe some geth dev can make things more clear.

[fjl]

We believe this is fixed on the master branch. Fast sync takes a while (especially with the mainnet), but will terminate eventually.

[vincentvc]

@brennino My eth.blockNumber shows 0 after almost several days sync. I am wondering whether the fast sync will fail if I stop and restart the sync process in middle for several times.

[manicprogrammer]

@vincentvc fast sync in geth only works when the database is empty thus you get one chance to fast sync and then it will be the full sync after that [STATED IN ERROR THE FOLLOWING- THIS IS INCORRECT AS POINTED OUT BY FJL: thus yes if you stop and restart anytime before that first fast sync finishes you won't do a fast sync from that point.] My experience with the scenario listed here was two fold. I used the latest build off of main and I made sure I had my database on an SSD. doesn't seem like the SSD vs HDD thing would matter so much but in my experience, until I put it on the SSD I could never get that first sync to finish up - not to say that is true for everyone just my experience.

[skarn01]

I'm having the same problem, continuous imported state I'm currently trying as @brennino says and will come back with result later... currently 350k states processed

here some info :

> eth.syncing
{
  currentBlock: 4269853,
  highestBlock: 4270000,
  knownStates: 357664,
  pulledStates: 348163,
  startingBlock: 4268019
}

net.peerCount 10

eth.blockNumber 0 update : almost 24h later here's the number blockNumber : 0

eth.syncing { currentBlock: 4270728, highestBlock: 4270793, knownStates: 6879452, pulledStates: 6875584, startingBlock: 4268019 }

imported state still going, gonna check back tomorow...

[brennino]

hi @skarn01 I don't know if this happen only to me but when I start fast sync with an empty block chain starting block always shows 0. You can see my eth.syncing on my previous post that I report here:

eth.syncing { currentBlock: 4249131, highestBlock: 4250814, knownStates: 25172364, pulledStates: 25170517, startingBlock: 0 }

Maybe something wrong happen during fast sync or you close geth before eth.blockNumber says a number near last block. Blockchain sync is really time consuming and you haven't to stop fast sync until finishes or eth.blockNumber != 0 and near highestBlock.

What can I tell for helping you... it seems you are not starting fast sync from an empty block chain so if I'm in you I will start again from the beginning.

If you don't want to start again (and I can understand you, I went crazy for days before having some results...) you have this opportunities:

1 - If you want just to make a transaction because ethereum are falling in price now and you are in panic you can use light sync for syncing, make your transaction and, when you stop praying and shout in your room for a price peak, try with calm to sync your blockchain with fast sync again. 2 - wait two days more with your current situation and see if something changes.

About point number 1, I think light sync is not an experimental feature any more (but maybe someone else can confirm)... and I succeed to make a transaction with a light sync blockchain without problems. If you want to start again with point number 2 later, you can close geth (because your situation is already corrupted) and rename your blockchiain directory .ethereum/geth. If you are ok instead for clear your current blockchain just use geth removedb on the operating system shell. After that, for starting light sync (different from fast sync!), I have started geth with the command: geth --light --cache=1024 and wait just 2 or 3 hour for download a 600Mb light blockchain. After that you can make your transaction. Again this is just my experience for helping people, no responsabilities if you lose your ethereum. Hope it helps Marco

[skarn01]

hi @brennino, you're right that strange that my starting block is not 0 as i haven't stop the geth daemon...

what i want to do is develop my own services using the chain ( got experience creating an ICO for my boss, now i got some interest in that technology ^^ ) so i don't worry for money i currently put here, there's currently none, ahah.

i'll try the --light option after the geth removedb. --light still give me possibility to work with the chain and see full block after the first sync?

Thank you and I'll come back with update on my situation.

[sonulrk]

I have tried -light option to check if it is experimental or not. I had used Geth 1.70 and in output it said light mode is experimental feature.

[fjl]

fast sync in geth only works when the database is empty thus you get one chance to fast sync and then it will be the full sync after that thus yes if you stop and restart anytime before that first fast sync finishes you won't do a fast sync from that point.

That's not quite true. Fast sync will continue after restart.

[fjl]

The original issue should be solved in the 1.7.0 release. If you fast sync with the release, it should stop eventually.

[sonulrk]

@fjl is right in v1.7.0 fast mode continue from the last receipt after restart. I have started sync with geth 1.7.0 from scratch. This is current system: Hardware: i5 2400, 16gb, hdd (deliberately use hdd instread of ssd to check the results) Softwares: Windows x64, geth 1.7.0 Network: 512kbps FTTH Command: geth --syncmode "fast" cache 1024

Let's see what happens.

Edit: geth is fully synced but minimum network speed should be 1 mbps. For initial 20 days it was running on 512kbps but it was not enough. So I increase the network speed to 1mbps and in 8 days it synced from 2.1 million to latest block. I am closing this issue because the initial problem of unbounded importing state entries is resolved in version 1.7.0. @nabeelamjad and @fjl are correct in their approach and information.

[nneverlander]

@sonulrk any update? I have the same problem as you. Current state:

eth.syncing { currentBlock: 4282458, highestBlock: 4282683, knownStates: 18160211, pulledStates: 18122951, startingBlock: 0 } Running for about 3 hours now

[NicholasB54]

I'm experiencing very similar problem using Geth1.7 & Mist 0.9.0 on Win10 Home However for me eth.syncing returns False and blockNumber returns 0

Started running Geth 1.7 yesterday afternoon after doing removedb and it completed sometime this morning, but wouldn't run the app (Mist)

I'm newbie just chipping in, (not a comprehensive posting .... but if problem persists I'll post more)

[vogelito]

Seeing the same problem on Geth 1.7.0

> eth.blockNumber
0
> eth.syncing
{
  currentBlock: 4285965,
  highestBlock: 4286240,
  knownStates: 512791,
  pulledStates: 506078,
  startingBlock: 4273567
}

[skarn01]

--light work well, but i want a fast sync has i can get full block, so i've try another time from scratch and geth got killed at 3.8M block i dont know why, i'm gonna upgrade to 1.7.0 and post what happen with my next try...

update : same prob, now syncing say false, blocknumber say 0, and i've got 13.5 M state processed and still going, I gonna post feedback later...

using geth 1.7.0

update2 : just been able to do a sync without problem (got some out of memory error, so i've close everything else while it was syncing) but still can't finish to sync... that one never stoped but the starting block doesn't show blocknumber 0...

eth.syncing { currentBlock: 4312845, highestBlock: 4313035, knownStates: 12114361, pulledStates: 12101760, startingBlock: 4312790 } eth.blockNumber 0

i'm gonna resign to use light mode for now, in hope everything I need will be there.

[skarn01]

to give you feedback.

i've update to geth 1.7.0, adjust my setting so there was no memory error ( got too many thing on my server, closed some of them) and followed @brennino procedure.

After a while, it was near completion (about 100-200 block away) and started to import states only. eth.sync stoped showing startblock:0 and was sometime restarting to sync the last hundred of block needed. At about 28M states processed, it stop importing states and started saying "new chain segment". So i've let it go until it finally got the last block (sync was sometime temporary stoping and took some minute to see that it was late and started again to sync, switching eth.sync from stats to false to stats...). At the last block, after eth.sync was saying false, and blocknumber was still going up and showing the same blocknumber as etherscan, i've stop geth and restart it.

Now everything seem fine. Took about 2-3days to do a fast sync. Approx half a day to 1 day for the first sync, 1day to import state, and some hour to finish syncing.

Now i hope my computer won't blow for the next few month, I don't want to start syncing again, ahahah.

Good luck to everyone else

[vogelito]

this eventually worked, but it was painful for sure.

[wtfiwtz]

Maybe you can try the light mode on the next time you need to start it from scratch!

https://github.com/ethereum/mist/issues/3097 🎉 and discussion here: https://github.com/ethereum/go-ethereum/issues/15001

[nabeelamjad]

I was away for a while and decided to do a fast sync to save some disk space by starting fresh, but ran pretty much in the same issue as described in this thread, here's what I did to solve it (using Geth 1.7.0):

Ensure you have an empty data directory, otherwise run your usual geth command followed with removedb at the end once to remove your DB.

1. Run geth --cache 2048 --datadir "D:/my/data/dir" (remove the -datadir argument if you want the default directory, the use of fast command wasn't required in 1.7 as it automatically assumes it)
2. When blockchain is nearing the highestBlock (about 100-150 blocks away) it will start importing a lot of state entries. Please let these complete, as of today this will be around 31 million state entries ( they go really fast).
3. Once all state entries are completed it will automatically start dropping stale peers, when this happens close geth entirely.
4. Repen geth using geth --syncmode "full" --cache 2048 --datadir "D:/my/data/dir" (syncmode is probably irrelevant)
5. Let it run for a while, it will reindex the chain and eventually auto-disable fast mode and switch to full mode. Took about 10 minutes for me during this stage.

Using the above settings, an SSD and a 220 Mbps download speed internet it took me roughly 1.5 hours to synchronize the blockchain from 0% to 99%, then the state entries took a good 3-4 hours before it finally finished. I think the keypoint is to let the state entries run until its completion, don't cut it off early. There's over 30 million state entries so it will take a while. Total blockchain size: ~26 GB from 0 to block 4351952 using the above steps.

I realize there's a light mode available, but it just doesn't cut it for me. I've tried it and it is very slow when submitting transactions (doesn't get picked up for a while or not at all when looping through 10-20 sendTransaction calls at once using web3, whereas the fast/full client picks them up instantly and I can see them on Etherscan).

Hope this helps.

[Roaid]

I suppose it is a wise choice you turn your geth syncmode to "full" mode.

[maverikou]

Just completed an import (--syncmode "fast" --cache=2048). "Imported new chain segment went" up to 14.7M in the process. Took about 6 hours. 38.4GB on disk.

[garyng2000]

sigh, all that is required is just some simple explanation of what 'fast' is doing(by the team), I was puzzled by what happened as well(and all those weird value when importing states, like ignored, duplicate what are they)

It seems what fast sync really does is :

1. download block headers all the way to almost as close as latest(4.7M as of Dec 15 2017)
2. download all states(but no verification) all the way to the latest(or may be close to)
3. since each block can contain multiple transactions(?) the # of state which is effectively a database transaction log can be much larger I think 48M as of Dec 15 2017
4. the 'processed=' is referring to the state record during the import state stage. So have to wait till this reaches 48M(in my case) and can be a gauge to guess when it will be done

Is this guess/interpretation correct ?

[ghost]

still not working

[xstalpha]

Did it ever finish?

[MilRefDev]

I can't get it to work either. I went into the geth directory and manually deleted the chain store folder using windows explorer. I then ran the command: "%APPDATA%\Ethereum Wallet\binaries\Geth\unpacked\geth.exe" geth --syncmode light

And all I currently see in CMD is just "imported new block headers" and "imported new block entries". Is this working correctly?

[garyng2000]

you would need to wait till you see import new state entries up until 50M(at least) before it starts the 'normal' full block sync for the remaining thousand or so. Given today's size, expect at least 2-3 days. Parity may be faster but never had an opportunity to do that to completion.

[garyng2000]

for light mode you should see the number to about 4.8M(as of today) and it is basically done

try 'geth attach' then 'eth.syncing' to check for the status

[xstalpha]

will update if it syncs

{ currentBlock: 4815023, highestBlock: 4815321, knownStates: 36384431, pulledStates: 36381874, startingBlock: 4810860

[garyng2000]

still have a while, the latest state is at least 50M and your's is only 36M

[xstalpha]

Yup. I ran Geth on Windows a few months ago and have let the node run since, but am migrating the node to a Linux machine. I keep seeing people asking this question repeatedly so if it does sync at ~50m I'll update and let everyone know it does actually work lol

[garyng2000]

I just created a new node in 'fast' starting yesterday and it is almost done now. again just some reference point for those who may need it:

As of Dec 28 2017: latest block was 4.8M, transaction state about 58M. it took me 26 hours or so to have it sync up and it is in the final stage(already switched to full node equivalent as that is the design of fast sync), about 300 block left the average disk usage is about 10-20MBps during the importing state stage and about 1-2Mbps in terms of network bandwidth I have to kill it once as it stalled for about an hour during the early importing state stage but it does know where to pick up again(so still sort of fast sync even after the restart). I think this is an improvement in 1.73 the total disk space used is 49GB

hope this help others in the future

edit: and it is fully sync now so this is now a node I can use for submitting transaction etc. about 5 minutes more when I first created this comment

[wwallace]

I left geth 1.73 running for about 15 hours geth --rpc --syncmode "fast" --cache 3096 --maxpeers 50 I was about 500 blocks away from highest block and knownStates was ~49M geth stalled for about 20 min, so I restarted. knownStates reset to 0 and is now going extremely slow. But disk usage is the same as before restarting.

Windows 10 SSD 16GB RAM 100Mbit connection