Afin d’économiser son disque dur, il est tout à fait possible de stocker en RAM les données d’un nœud Duniter (grâce au /dev/shm de Linux par exemple).
Par contre sur un Raspberry Pi 3 avec entre 600 et 700 Mo de mémoire libre je n’ose pas trop… les données de Duniter prennent au total 700 Mo, dont 100 Mo de logs et plus de 500 Mo pour la blockchain en JSON. D’ailleurs j’ai l’impression que archives et g1 contiennent exactement la même chose, à un crochet près. Est-il important de garder les deux ?
Ce serait bien de pouvoir choisir la quantité de lignes de logs à conserver (dans la config je n’ai trouvé que le niveau de log, ou alors j’ai mal cherché).
Donc si on peut choisir de garder moins de log et ne pas dupliquer les données en JSON, on peut économiser plus de 300 Mo, et si le stockage en JSON est optionnel, on peut même économiser 550 Mo (après tout, la blockchain est déjà stockée dans la bdd). Il serait donc possible de ne pas se prendre la tête pour installer un disque dur sur le RPi…
Oui, j’ai également remarqué qqch de similaire à ta remarque. Il doit y avoir qqch à faire de ce côté.
Pourrais-tu ouvrir un ticket pour explorer ça ?
Il y a l’outil syslog qui gère ça. Après, je sais pas si une gestion intégrée à Duniter serait intéressante. Il y a déjà une rotation des logs, dès que le fichier atteint 50 Mo, il est zippé. Un autre ticket ?
Les blocks jsons, je suppose qu’ils permettent à d’autres noeuds de se synchroniser.
je suis curieux, très curieux, de voir un benchmark de cette idée, Je doute que la mise en RAM change grand chose, mais l’expérience vaut mieux que tout les arguments qui me font penser cela.
je te suggêres si celà t’intêresse de benchmark avec un hdd 5400 rpm, un 7200 rpm mais surtout avec des mêmoire flash.
par contre l’argument qui dit “économiser” un disque dur en utilisant la RAM lui est très douteux, les couts de production, consommation éléctrique (qu’il serait intéressant de mesurer d’ailleurs), resynchro à chaque demarrage, … tout suggère que c’est pas très “économique” d’utiliser une mêmoire temporaire pour persister une donnée. d’un point de vue pédagogique en revanche, cela, sans doute, à de la valeure.
EDIT
Pour les logs, est-ce que duniter
log vers un fichier puis tail -f en console (auquel cas, il faut supprimer l’archivage)
log vers la console + log vers un fichier (auquel cas /dev/null et le tour est joué)
Je pense qu’avec un RPi, exploiter la RAM est bénéfique puisque ça évite d’écrire plein de fois dans la carte SD qui s’use vite (on écrit à chaque arrêt, ou périodiquement par sécurité) ; ça évite d’avoir un HDD qui tourne en permanence (=> conso électrique, usure, coût élevé).
En effet ce n’est pas logique d’utiliser une mémoire volatile pour du stockage. On pourrait alors mettre tout ce qui est immuable dans le disque (les archives en JSON par exemple, auxquelles on ajoute des données sans cesse mais qu’on ne modifie jamais) et ce qui est modifié en permanence en mémoire (les indexes). Techniquement ça doit être possible sans modifier le code de Duniter, mais vraiment pas très propre.
Je regarderai ce soir pour les logs et les issues.
Pour ma part, mes raspi n’ont aucun disque dur depuis le début. Bien sûr, en terme de durée de vie des cartes SD, c’est pas terrible, mais pour l’instant je n’ai pas eu de problème de ce côté-là. En revanche, je fais tourner aussi un nœud sur un bananapi avec un disque SATA dessus - la performance en SATA n’a du coup rien à voir avec l’USB2 du raspi…
Après ce qui épuise la carte à mon avis, c’est surtout les resynchros, pas vraiment l’écriture de nouveaux blocs - le reste du temps duniter ne fait que de la lecture ce qui ne pose pas vraiment de problème.
Oui oui mais si l’implémentation a changé, le concept reste le même - on écrit le fichier et on l’affiche à l’écran ensuite, il n’y a pas de potentielle redirection des outputs vers stdout en parallèle comme cherche à le savoir @Junidev. Par contre, pendant que j’y pense on peut très bien lancer duniter en mode direct_start pour qu’il affiche ses outputs directement à l’écran plutôt que dans le fichier de logs (confirmé à l’instant sur mon raspi). Quitte à le lancer dans un script en boucle pour qu’il redémarre s’il plante (un simple while [ true ] ; do duniter direct_start; done suffit en fait). L’inconvénient étant que si on a un plantage, on n’a justement pas de logs pour analyser ce qui a foiré.
Par contre, pendant que j’y pense on peut très bien lancer duniter en mode direct_start pour qu’il affiche ses outputs directement à l’écran plutôt que dans le fichier de logs (confirmé à l’instant sur mon raspi). Quitte à le lancer dans un script en boucle pour qu’il redémarre s’il plante (un simple 
