Confusion/Issue using Workspace-snapshot.sh with Pruned Snapshot (pruneancient)

[hakiran16]

Hello BSC Snapshot Maintainers,

I am trying to set up a pruned BSC mainnet node on Ubuntu (using ~3.65TB NVMe SSD) with the latest official geth client binary (1.5.9 downloaded from bnb-chain/bsc releases). I am using the Workspace-snapshot.sh script from this repository but encountering issues specifically with the pruned snapshots.

Environment:

OS: Ubuntu 22.04/24.04 (User can specify)
Client: geth-bin (from bnb-chain/bsc) version 1.5.9
Disk: ~3.65 TB NVMe SSD
Target Snapshot Type: Pruned Mainnet (latest available, seems to be pruneancient)
Workspace-snapshot.sh: Latest version downloaded from this repo on Apr 10/11, 2025.
Snapshot Identifiers (from README around Apr 10/11, 2025):

Full: mainnet-geth-pbss-20250404 (~3TB)
Pruned: mainnet-geth-pbss-20250404-pruneancient (~900GB, requires >=v1.5.5)
Attempts and Issues:

Attempt 1: Using -p flag with -pruneancient identifier:

Command:
bash ./fetch-snapshot.sh -d -e -c -p --auto-delete -D "/home/bsc_data/downloads" -E "/home/bsc_data/node/geth/chaindata" "mainnet-geth-pbss-20250404-pruneancient"
Result: Failed immediately with a 404 Error trying to download the metadata CSV file. It seemed to incorrectly generate the URL by duplicating the suffix: .../mainnet-geth-pbss-20250404-pruneancient-pruneancient.csv
Error Log Snippet:
try to download mainnet-geth-pbss-20250404-pruneancient-pruneancient.csv ...
... ERROR 404: Not Found.
Attempt 2: Using -p flag with BASE identifier (as per script examples):

Command:
`Bash

bash ./fetch-snapshot.sh -d -e -c -p --auto-delete -D "/home/bsc_data/downloads" -E "/home/bsc_data/node/geth/chaindata" "mainnet-geth-pbss-20250404"`

Result (on first try): The script ran, but downloaded and extracted the Full Snapshot data, resulting in ~3.5TB in the chaindata directory (du -sh confirmed) and filling up the 3.65TB disk, causing the node to fail later. This contradicts the expectation of getting the ~900GB pruned data when using the -p flag. (Note: I am currently re-running this exact command one last time while carefully monitoring disk usage).
Attempt 3: Manual Download & Extract of pruneancient files:

Manually downloaded the two files associated with pruneancient (...base-48055283.tar.lz4 and ...blocks-pruneancient-47965283.tar.lz4) using their direct URLs.
Manually extracted using lz4 -d ... | tar xvf - ... (base first, then blocks-pruneancient into the same target directory). Extraction completed without errors, du -sh showed ~970GB.
Started node using this data:
`Bash

In /home/bsc_data/node

nohup ./geth-bin --config ../config/config.toml --datadir ./geth --cache 18000 --txlookuplimit 0 --http --http.addr --http.port 8545 --ws --ws.addr --ws.port 8546 &> bsc_node.log &`

Result: Node started, RPC was responsive, but eth_syncing showed currentBlock: 0x0, highestBlock: 0x0, and all state counters zero initially. After a while, highestBlock updated correctly (~48M) but currentBlock remained very low (~157k) with startingBlock: 0x0 and zero state counters, indicating it defaulted to syncing from genesis and failed to use the manually extracted pruned data. eth_getBlockByNumber failed for blocks like 10M and 47M (returning null).
Questions:

What is the correct combination of snapshot identifier and flags (specifically -p) to reliably use Workspace-snapshot.sh to download and extract the pruned (pruneancient) snapshot?
Is there a known issue with the script's handling of the -p flag or the pruneancient identifier for the mainnet-geth-pbss-20250404 version?
Is the expected final size of the chaindata directory after using the pruneancient snapshot indeed around ~900GB - 1TB?
Could the manual extraction failure indicate an issue with the pruneancient snapshot files themselves, even if they extract without tool errors?
Any clarification or guidance would be greatly appreciated. Thank you!

[hakiran16]

Update: Problem Solved: Switched BSC Client Version to v1.5.7

Hello,

Quick update on the issue I reported regarding difficulties using the Workspace-snapshot.sh script and the mainnet-geth-pbss-20250404-pruneancient snapshot.

The problem has been resolved.

Solution:
The issue appears to have been related to the BSC Geth client version. I was initially using v1.5.9 (latest at the time). With v1.5.9, the node failed to initialize correctly from the pruned snapshot data (both when extracted manually and when extracted via the script using -p flag + base identifier), and it consistently defaulted to syncing from genesis (block 0), showing startingBlock: 0x0 in eth_syncing.

Following suggestions, I switched the client binary to version v1.5.7 (downloaded geth_linux from the v1.5.7 release) while keeping the exact same pruned snapshot data (~970GB) in the chaindata directory (extracted using the script with -p and the base identifier mainnet-geth-pbss-20250404).

After starting the node with the v1.5.7 binary, it successfully loaded the pruned snapshot data and immediately entered the state sync phase as expected.

Current Status:
The node running v1.5.7 is now actively syncing state. The eth_syncing output correctly shows the highestBlock and non-zero values for startingBlock and currentBlock. For example, the last check showed:

'JSON

{
"currentBlock": "0x5cde49", // Approx 6.1M
"highestBlock": "0x2e06623", // Approx 48.2M
"startingBlock": "0xbf6ed", // Approx 784k
// ... other state counters increasing ...
}'
(Note: eth_blockNumber still reports 0x0 during this state sync phase with v1.5.7, but eth_syncing clearly shows progress).

Conclusion:
It seems there might be an incompatibility or a regression in v1.5.9 specifically related to initializing from the pruneancient PBSS snapshot type. Version v1.5.7 handles the same data correctly.

Hopefully, this information is helpful for the maintainers and anyone else encountering similar issues.

Thanks.

[frankandrea221]

1. Fast‑sync’s “invisible” block count
   In Geth v1.5.7 you’re almost certainly running in fast sync mode (the default for a new node). During that phase:
   • Headers and state trie snapshots are being downloaded and verified.
   • Full block bodies aren’t being fully processed until you hit the “pivot” block.
   As a result, eth_blockNumber will stubbornly stay at 0x0 until you finish that pivot → state import dance. Meanwhile, eth_syncing’s currentBlock and highestBlock fields are your real progress bars.
   2. Trust eth_syncing, not eth_blockNumber
   • Poll eth_syncing every few seconds:

{
"jsonrpc":"2.0",
"method":"eth_syncing",
"params":[],
"id":1
}

Look at currentBlock / highestBlock to gauge completion.

•	Once you hit the pivot, Geth switches gears, processes the downloaded state, then eth_blockNumber will leap up to match the chain head.

3.	Pro tips to stay in control
•	Upgrade Geth: v1.5.7 is ancient. Modern versions (1.10.x+) use warp sync and expose richer sync metrics (e.g. warpSnapshotStage, fastSyncStage).
•	Watch the logs: Start Geth with --verbosity 3 (or higher) to see lines like

INFO [02-14|10:12:34] Imported new state entries count=… elapsed=… processed=…

That tells you state import is humming along.

•	Check peer count: net_peerCount should be > 0. If you’re starving for peers, sync crawls to a halt.

4.	A quick metaphor

Think of your node as planting a tree: first you dig the hole and lay down the roots (headers and state trie), then you pour in the soil and water (block bodies). Only when the roots are set does the trunk (your eth_blockNumber) start to grow.
5. Next steps
• Confirm you really are in fast sync: did you launch with --syncmode “fast” (default)?
• If you need a quicker ramp‑up and are on a beefy machine, try warp sync on a newer Geth:

geth --syncmode “snap” --cache=4096

•	Keep polling eth_syncing until it returns false, then eth_blockNumber will finally reflect the live chain.