Support for reducing disk space requirements

[mdehoog]

Add $OP_GETH_GCMODE and $OP_GETH_STATE_SCHEME envvars for overriding the --gcmode and --state.scheme op-geth arguments:

• Setting OP_GETH_GCMODE=full allows people to run a full node instead of an archive node
• Setting OP_GETH_STATE_SCHEME=path switches the ethereum state storage scheme to path (defaults to hash)

Also updates the README clarifying disk space requirements.

[roberto-bayardo]

FYI I tried syncing with state-scheme=path and ended up with a corrupted DB. Seems the geth devs have a patch for the issue but it's not in any release yet, and not clear when it will make its way into op-geth. I'd recommend NOT using it for now.

[adapt7]

@roberto-bayardo @mdehoog sorry if question is dump but I had full node fully synced and added OP_GETH_STATE_SCHEME=path to the .env and rebuilt the docker. Should I wait for lower disk usage that will happen automatically or do I have to clear geth-data and re-sync from scrach?

[roberto-bayardo]

If you changed state-scheme to PATH you'll need to delete the old DB for it to apply. it's a totally different DB format.

The real space saver though is to set OP_GETH_GCMODE=full

[adapt7]

I set:

OP_NODE_SYNCMODE=execution-layer
OP_GETH_SYNCMODE=snap

and now there is zero connected peers after few days. What can be the problem?

If I change mode to full, isn't it the previous one that was by default? By looking at geth-entrypoint:

geth-entrypoint:OP_GETH_GCMODE="${OP_GETH_GCMODE:-full}"

It looks like "full" was default. What do you mean that changing to "full" is a space saver?

[roberto-bayardo]

We're aware of the lack of peer availability for snap/execution sync, though don't have an ETA on a fix. In the meantime you may have to switch back to standard sync mode.

re: full, yes looks like it is the default now. It was archive at one point.

[adapt7]

Now I understand, the defaults to "full" was introduced sometime earlier this month while I installed node before that so I had "archive", hence my node consumed over 3.5T disk space.

The "snap" mode still doesn't seem to work so I'm switching to "full".

@roberto-bayardo do you know how many blocks back the "full" node will offer to read data from? Is it this amount of blocks configurable? How about prune - is it implemented and "full" node will clear disk space at some point or only grow up heavily similar to archive node?