I was used to sync a grin node for the first month of mainnet. I recently updated to grin 1.0.2 and rebuild my node from scratch, only keeping the wallet files in the ~/.grin directory. I didn’t keep any chain data.
Unfortunately, the nodes is stuck at 58% while sync’ing (step 2/4). Environment is Linux.
I’ve deleted the chain_data folder and restarted again, same result.
What should I do ? Is there any bootstrap file anywhere ?
20190324 02:36:04.025 ERROR grin_p2p::protocol - handle_payload: txhashset archive save to file fail. err=Connection(Os { code: 28, kind: Other, message: "No space left on device" })
Problem, I do have space left :
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 118G 14G 100G 12% /
I also tried twice on 2 different ubuntu server… The problem remains the same !
I kinda wonder how using the grin node ends up on this error…
Chain data is less than half a gig atm… Maybe you should be looking at the filesystem mounted in your home directory instead of root (in case it’s separate)? You said you tried in two separate machines so that’s weird. It may be something funky going on with lmdb? @igno.peverell@antioch
Ubuntu comes with a default /tmp size of 100Mb. Now the chain is 180Mb. I don’t get why the GRIN node is going through the /tmp directory instead of directly writing into the ~/.grin/main/ directory, or why it doesn’t write it piece by piece, but that’s definitely a pain. And this problem might increase with time. Not a lot of people has a 1Gb mounted on /tmp
Here is the actual line in the code. It’s usual for apps to use temp directories but I am not sure either why it’s needed in this case. You may be able to work around the problem by passing a custom TMPDIR to the grin process if you cannot change the partition table.
Yeah it’s usual for apps to use the /tmp directory, but most of the time, the nodes split the chain through many files to avoid this kind of disk space problem. Anyone starting a new node might go through the same situation in the future with the chain size increasing.