Forum Programmation.autre Nombre de fichiers dans un dossier

Posté par  .
Étiquettes : aucune
2
4
fév.
2011
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  . Évalué à -1.

    En général,Le système parcourt la liste des fichiers dans un dossier de manière linéaire.
    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  . Évalué à 4.

    voir l'option dir_index

    • [^] # Re: man mkfs.ext3

      Posté par  . Évalué à 3.

      \o/

      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  (site web personnel) . Évalué à 2.

      Aussi disponible pour ext4 !

      Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: man mkfs.ext3

      Posté par  . Évalué à -1.

      Merci c'est bon à savoir.

      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  . Évalué à 2.

        Ça doit se jouer à quelques cycle de cpu ça. À mon avis, ça change rien du tout au niveau de la fragmentation.

        Envoyé depuis mon lapin.

        • [^] # Re: man mkfs.ext3

          Posté par  . Évalué à -2.

          Non, pour ma part, c'est clairement long à sauvegarder plusieurs milliers de petits fichiers mais je ne suis pas sur ext3 ou ext4 dans ce cas.
          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  . Évalué à 2.

            Ça doit venir du système de sauvegarde qui est lent pour gérer chaque fichier.

            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  . Évalué à -3.

              Je pense que çà vient du déplacement de la tête de lecture dans le disque.

              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  . Évalué à 2.

                Oui, mais quand tu fais ton .tar, il accède lui aussi à des fichiers fragmentés.

                Envoyé depuis mon lapin.

  • # Avec la DirDB de Kyoto Cabinet

    Posté par  . Évalué à 1.

    KyotoCabinet, avec sa DirDB, te permet de stocker des gros blobs tout simplement sous forme de fichiers, en y ajoutant compression, transactions, et d'autres fonctionalités de base de données. Les docs: Et l'annonce: Ça tiendra mieux la charge que n'importe quelle base qui repose sur un stockage monolithique. Sinon la DirDB a une variante, la ForestDB, qui ajoute une notion d'arbre et permet d'énumérer les documents dans un ordre précis. Je ne crois pas que ce soit nécessaire ici.

  • # Commentaire supprimé

    Posté par  . É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.