Juste pour donner une idée des ordre de grandeurs en causes. Sur un serveur de sauvegarde (BackupPC, un petit, j'en ai un plus gros, mais faire des stats dessus pendrait trop de temps), qui fonctionne depuis une demi année (ce qui limite le nombre de hard-link), pour seulement 324 GiB, j'ai 4 millions d'inodes, et 56 millions de links (pour rappel, un fichier normal, c'est un inode + un link vers l'inode). C'est seulement sur 6 mois avec 324 GiB.
Dans le cas de l'auteur, avec un truc qui tourne depuis 6 ans, et 2TiB de données, en gardant une granularité quotidienne (ce que je ne fais pas), si j'extrapole avec mon nombre de sauvegarde conservées et en considérant que le nombre de links par inode est une proportionnel au nombre de sauvegarde conservés, et que le considère que le nombre d'inodes est proportionnel au volume de données, cela donne 23 millions d'inodes et 27 milliards (oui 109) de links. Alors je ne connais pas exactement les chiffres de l'auteur du journal, mais on est loin de tes 2·105 à 3·105 inodes, et quelques millions de links.
C'est justement stockage de cette équivalence entre links et inodes au fur et à mesure de la rencontre des links qui est problèmatique.
Je me demande si par ailleurs, il n'y aurait pas moyen de développer un outil spécifique qui stockerai ces infos dans un stockage key/value adaptés aux très gros volume de données (dans le genre de LMDB).
[^] # Re: Ton NAS a un problème
Posté par jben . En réponse au journal Mon Backup de backup. Évalué à 3.
Juste pour donner une idée des ordre de grandeurs en causes. Sur un serveur de sauvegarde (BackupPC, un petit, j'en ai un plus gros, mais faire des stats dessus pendrait trop de temps), qui fonctionne depuis une demi année (ce qui limite le nombre de hard-link), pour seulement 324 GiB, j'ai 4 millions d'inodes, et 56 millions de links (pour rappel, un fichier normal, c'est un inode + un link vers l'inode). C'est seulement sur 6 mois avec 324 GiB.
Dans le cas de l'auteur, avec un truc qui tourne depuis 6 ans, et 2TiB de données, en gardant une granularité quotidienne (ce que je ne fais pas), si j'extrapole avec mon nombre de sauvegarde conservées et en considérant que le nombre de links par inode est une proportionnel au nombre de sauvegarde conservés, et que le considère que le nombre d'inodes est proportionnel au volume de données, cela donne 23 millions d'inodes et 27 milliards (oui 109) de links. Alors je ne connais pas exactement les chiffres de l'auteur du journal, mais on est loin de tes 2·105 à 3·105 inodes, et quelques millions de links.
C'est justement stockage de cette équivalence entre links et inodes au fur et à mesure de la rencontre des links qui est problèmatique.
Je me demande si par ailleurs, il n'y aurait pas moyen de développer un outil spécifique qui stockerai ces infos dans un stockage key/value adaptés aux très gros volume de données (dans le genre de LMDB).