# Soucis potentiel d'espace disque nécessaire pour la V2
**URL:** https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780
**Category:** Duniter-v2
**Tags:** gdev
**Created:** [13 December 2024 14:58 UTC](https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780 "2024-12-13T14:58:31Z")
**Posts on this page:** 5
**Page:** 2
### Author:  [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [19 March 2025 11:19 UTC](https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780/21 "2025-03-19T11:19:13Z")
J’avoue que je ne saisis pas la nuance entre `block pruning` et `state pruning`; ni entre `block` et `state` quelle partie prend beaucoup d’espace disque.
Quand on spécifie la variable d’environnement:
```yaml
DUNITER_PRUNING_PROFILE=light
# OU
DUNITER_PRUNING_PROFILE=archive
```
Est-ce que cela impacte les 2 “types” de pruning ?
Et du coup ma question plus globale est quelle est la configuration minimale pour que l’on puisse utiliser un noeud duniter comme source de synchronisation d’un nouveau noeud - et quel serait l’espace disque utilisé avec cette configuration ?
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [19 March 2025 16:33 UTC](https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780/22 "2025-03-19T16:33:42Z")
> [@Nicolas80](#):
>
> J’avoue que je ne saisis pas la nuance entre `block pruning` et `state pruning`; ni entre `block` et `state` quelle partie prend beaucoup d’espace disque.
Les blocs décrivent les transitions d’états. C’est léger puisqu’on en broadcast toutes les 6 secondes.
Un état est tout le storage à un numéro de bloc donné. C’est lourd et ça le sera de plus en plus.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [19 March 2025 19:18 UTC](https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780/23 "2025-03-19T19:18:22Z")
Sachant que les nœuds archive stockent le storage pour tout les blocs et que les indexers ont principalement besoin de :
- Historique des Virements (extrinsics ?)
- Pseudonymes des identités (événements ?)
A-t-on vraiment besoin d’un nœud archive pour l’indexer ?
Ne peut -on avoir les deux infos plus lentement, mais aussi surement avec les nœud miroir (ou bien les événements sont aussi stockés dans le storage ?)
Idée à la con :
- On a aucun nœud archive sur notre réseau, car c’est le mal !
- Un indexer qui se lance, regarde le bloc courant de son nœud miroir, et s’y abonne pour capturer les infos au fil des blocs. Puis lance en parallèle un nœud archive temporaire, juste pour y puiser ce qui lui manque entre le bloc genesis et le bloque courant. Puis éteint et supprime le nœud archive ! CQFD !
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 March 2025 20:14 UTC](https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780/24 "2025-03-20T20:14:02Z")
> [@Nicolas80](#):
>
> la nuance entre `block pruning` et `state pruning`; ni entre `block` et `state`
La réponse courte de tuxmain est bien. Si tu veux un peu plus d’explications, tu en trouveras ici : [Élagage de l'état, élagage des blocs, noeuds archive et miroir](https://forum.duniter.org/t/elagage-de-letat-elagage-des-blocs-noeuds-archive-et-miroir/12255).
> [@vit](#):
>
> A-t-on vraiment besoin d’un nœud archive pour l’indexer ?
L’indexeur a besoin uniquement des événements qui devraient en théorie pouvoir être récupérés sans nœud archive. En pratique squid est basé dessus donc ça demanderait des développements significatifs en plus.
J’ai posé la question sur le github de substrate, et apparemment on pourrait implémenter l’élagage des headers pour gagner de la place :
>
>
> My issue is that disk space usage is difficult to predict.
>
> As asked here (https…://git.duniter.org/nodes/rust/duniter-v2s/-/issues/267) it keeps growing even when block pruning is set.
>
> And without block pruning, is there some work to predict the state growth for empty block production? Some profiling showed us that this growth is non-linear: https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/267.
>
> It would be very nice to give an upper limit of disk use depending on pruning settings in order to know how to tune the pruning settings to run on a machine with finite disk space.
Reste à faire des calculs (au moins en ordre de grandeur) de qu’est-ce qui prend quoi comme place.
---
### Author:  [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [19 April 2025 10:55 UTC](https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780/25 "2025-04-19T10:55:18Z")
J’ai dû stopper mes serveurs **Archive & Squid/Indexer** sur mon 1er serveur oracle car ils occupaient à eux deux **66GB** et j’arrivais dangereusement proche de la limite de mes 200 GB de disque.
Juste avant de les retirer, j’ai extrait une dernière vue des usages disque des volumes docker de mon serveur (un relevé par jour depuis le 27/11/2024) :
[docker-volumes-sizesMB-logs\_20250418.ods](https://forum.duniter.org/uploads/short-url/1fD2lQhqMIs8PBIBfdGxPJuc5VR.ods) (49,5 Ko)
Pour info, les endpoints **retirés** :
- (RPC) wss://archive-rpc.gdev.brussels.ovh/ws
- (SQUID) [https://squid-hasura.gdev.brussels.ovh/v1/graphql](https://squid-hasura.gdev.brussels.ovh/v1/graphql)
J’ai également ajouté une [MR pour faire le nettoyage dans le fichier gdev.json](https://git.duniter.org/nodes/networks/-/merge_requests/3)
[Previous page](https://forum.duniter.org/t/soucis-potentiel-despace-disque-necessaire-pour-la-v2/12780.md?page=1)