Bonjour, suite à l'annonce de mon projet qui consiste à sauvegarde le web (oui oui), je m'apprête à devoir stocker énormément de fichiers.
Chaque fichier sera identifié par une somme de contrôle, comme une clef hexadécimal à 40 chiffres.
Je sais qu'il y a de nombreux programmes qui font des sous dossiers pour améliorer les performances.
Je pourrais m'amuser à séparer la clef en un chemin de dossiers.
Le fichier aabbccdd pourrait être dans le dossier aa/bb/cc avec un nom dd.
Si je prends des groupes de 2 chiffres, il y a 256 dossiers à la racine. Avec 3 chiffres, ça monte à 4096, et à 4 chiffres, il y a 65536 dossiers à la racine.
Il faut aussi optimiser le nombre de dossiers à parcourir récursivement. Je ne sais pas si il vaut mieux parcourir 20 dossiers à 256 fichiers au maximum, ou 10 dossiers à 65536 fichiers au maximum…
Est-ce que c'est s’embêter pour rien, si le système de fichiers utilise déjà un arbre pour repérer les noms de fichiers ?
Je pourrais aussi tout mettre dans un seul dossier, et dans une base de de données, stocker les relations entre les clefs (noms des fichiers) qui sont primaires et sous forme d'arbre, et le numéro d'inode des fichiers.
Vous, vous feriez comment ?
# Par experience
Posté par syj . Évalué à -1.
ce n est pas gênant pour un dossier contenant moins de 100 ( sauf si il est parcouru très souvent, là çà peut devenir problématique).
Par contre, çà devient lourd quand le dossier contient plusieurs milliers de fichiers.
Tu le sens alors que ce n'est pas du log(n).
par exemple, j ai vu des sauvegarde exploser en temps à cause de répertoire contenant prêt 60 000 fichiers.
un tar du lot est tu sauvegarde la même chose en beaucoup moins de temps.
# man mkfs.ext3
Posté par netsurfeur . Évalué à 4.
[^] # Re: man mkfs.ext3
Posté par yellowiscool . Évalué à 3.
Un message privé m'avait fait remarquer qu'il n'était pas la peine de faire plein de sous dossiers pour avoir un arbre assez efficace, mais avec cette option, cela devient super facile.
Surtout qu'elle est activée de base dans ma distribution. Suffit de t out mettre dans un dossier, sans s’embêter :-)
Envoyé depuis mon lapin.
[^] # Re: man mkfs.ext3
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: man mkfs.ext3
Posté par syj . Évalué à -1.
Je me poserai quand même la question du problème de la sauvegarde.
L'ensemble des données vont être fragmenter sur le disque du fait de la multitude de fichier ?
A moins de sauvegarder la partition d'un coup, la sauvegarde risque d'être très longue car elle nécessitera beaucoup d'accès disque.
[^] # Re: man mkfs.ext3
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: man mkfs.ext3
Posté par syj . Évalué à -2.
Enfin, j'ai eu ce problème sur une partition jfs2 d'un aix. Je "tar" tous les mois , l'ensemble des messages reçu pour éviter que mes temps de sauvegardes explosent.
Enfin, si tu parts du principe que tu sauvegardes la partition d'un coup et qu'avec lvm , tu t'arranges pour avoir juste l'espace libre nécessaire, tu peux sauvegarder le tout avec un dd et au final, çà te fait un peu comme une base de données que tu sauvegardes à froid.
[^] # Re: man mkfs.ext3
Posté par yellowiscool . Évalué à 2.
Car entre sauvegarder chaque fichier, et mettre chaque fichier dans un .tar, et sauvegarder le .tar, c'est presque pareil. Le tar va bien à un moment ou à un autre accéder à chaque fichier du dossier :-)
Envoyé depuis mon lapin.
[^] # Re: man mkfs.ext3
Posté par syj . Évalué à -3.
Les fichiers ne sont pas forcement contigue sur le disque. La lecture est donc fortement fragmenter. Ce sont des fichiers de quelques ko à chaque fois.
[^] # Re: man mkfs.ext3
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
# Avec la DirDB de Kyoto Cabinet
Posté par Tobu . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.