1

I'm running a Polkadot and a Kusama node on (separate) docker containers. Both are archive nodes, so it takes some more space (according to the wiki 15 to 20 Go). I was counting on the fact that 1) the nodes will grow with time and 2) Docker volumes may take more space than expected. However both volumes are just huge compared to what I expected. Data are from the nodes obviously, and no other container are using these volumes. So the issue should come from the Polkadot and Kusama nodes.

Here is the result of docker system df -v :

Local Volumes space usage:

VOLUME NAME                                                        LINKS     SIZE
polkadot-node                                                      0         340.3GB
kusama-node                                                        0         449.6GB
766d53de4186afe3fd9e9ccd8749bce3747a8e806638eac319d023b1b38be30b   0         4.803kB
0086e5137317bd84b06145a8c61efac31071c195aecb0127bd8520fbc367d441   0         4.803kB
a1f9e73a691743af61386d5d52bf816c21e8f7ae39c8972647cb67d66f3a41eb   1         205.7MB

Build cache usage: 0B

CACHE ID   CACHE TYPE   SIZE      CREATED   LAST USED   USAGE     SHARED

Here are the docker-compose files for both nodes (other services omitted), the only difference is that everything named "kusama" can be replaced by "polkadot" :

version: "3.8"
services: 
    kusama-node: 
        image: parity/polkadot:latest
        volumes:
            - kusama-node:/data
        container_name: kusama-node
        command: '--name "CrommVardekNode" --chain kusama --unsafe-ws-external --pruning archive --rpc-cors=all --base-path /data/polkadot --wasm-execution Compiled'
        ports:
            - "127.0.1.1:30333:30333"
        networks:
            - kusama

networks:
    kusama:
        external: true

volumes:
  kusama-node:
    external: true

Why do the volumes take so much disk space ? (Note, the nodes were not even completely synced (about 90%))

2 Answers 2

4

The wiki says that it was 15 to 20GB around Kusama's 1.6 millionth block.

Kusama is now at > 12 million blocks.

Taken from the docs:

Archive node

An archive node does not prune any block or state data. Use the --pruning archive flag. Certain types of nodes like validators must run in archive mode. Likewise, all events are cleared from state in each block, so if you want to store events then you will need an archive node.

1
  • 1
    This is the part I didn't read properly, the fact that the size they gave (15 to 20 GB) is for 1.6M blocks... So yes, the size I had on my volumes make more sense now. Thanks for the information.
    – Cromm
    Apr 25, 2022 at 5:41
3

when running nodes with --pruning=archive, there is sadly no silver bullet that will free up space for you -- you are specifying to keep all state data from block 0, and that slowly grows. The space listed for kusama and polkadot seems about right.

I'd be curious to hear why you need to use the archive flag, running without it definitely saves space and works for most use-cases

1
  • There are times I need information that are from up to 2 year old. More exactly I query the block heigh of blocks that could be up to 2 years old to have the timestamp of the block. Sadly before I needed that information I was using a non-archive node.
    – Cromm
    Apr 25, 2022 at 5:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.