Forum Programmation.autre Pré-réserver de l'espace sur le disque dur

Posté par  .
Étiquettes : aucune
1
27
nov.
2009
Bonjour à tous,

Je travaille actuellement sur un projet qui écrit beaucoup de données directement sur le disque dur, dans des fichiers d'environ 30 Ko. Or, initialement, les fichiers ne font que 10 Ko, voire moins, et c'est au fur et à mesure du temps qu'ils atteignent la taille de 30 Ko.
Un benchmarking portant sur la vitesse de lecture, écriture et accès nous a fait choisir ReiserFS comme système de fichiers.

Afin d'accélérer la lecture de ces fichiers, je souhaiterais dire au filesystem de pré-réserver 30 Ko pour chaque fichier, au moment de leur création. Ceci afin d'éviter la fragmentation et d'accélérer la lecture des données.

J'ai lu pas mal de doc sur les extents et autres et je pense être sur la bonne voie. Cependant, je ne vois pas comment dire au filesystem de me pré-réserver de l'espace. Tout d'abord, est-ce possible ? Que dois-je appeler comme fonction ?

Le développement est fait en Perl, cependant si je trouve une solution en C, je serai preneur. Il y a des bindings et j'ai le droit de faire du "sale".

Merci d'avance pour vos lumières.

  • # Idée simpliste

    Posté par  . Évalué à 4.

    Ajouter du padding (des \zéros par exemple) à la fin de ton fichier pour qu'il prenne dès le début sa taille maximale...

    • [^] # Re: Idée simpliste

      Posté par  . Évalué à 2.

      C'est effectivement la bonne méthode, mais Posix offre déjà un jeu de fonctions pour définir/ajuster la taille d'un fichier ==> truncate/ftruncate

      • [^] # Re: Idée simpliste

        Posté par  . Évalué à 1.

        Effectivement, c'est déja mieux. Je ne connaissais pas ces fonctions.

        Existe-t-il des fonctions du même ordre permettant de s'assurer que les blocs sur le disque sont consécutifs (pas de fragmentation) ?

        • [^] # Re: Idée simpliste

          Posté par  . Évalué à 3.

          éventuellement posix_fallocate ou fallocate qui mappent l'appel système fallocate. Le premier n'est pas supporté par tout les systèmes de fichiers (dans ce cas, il se contente d'écrire des zéros ce qui est nettement moins performant), le second est un appel linux-only mais n'a pas les mêmes problèmes que son homologue posix.
          Dans ce cas, pas besoin de ftruncate, mais il vaut mieux prévoir large dés le départ et ensuite redimensionner son fichier.

          Le commentaire d'eMerzh me semble pertinent pour ce problème
          http://linuxfr.org/comments/1085943.html#1085943

          • [^] # ext4 et xfs et btrfs

            Posté par  (site web personnel) . Évalué à 4.

            l'appel système fallocate est reconnu par les fs ci-dessus mentionnés : ext4, xfs, btrfs. (ou il l'implémente tout simplement ?) Donc ils allouent des extents pour la taille du fichier demandé. pas besoin de remplir de zéro.

  • # Comment font..

    Posté par  . Évalué à 3.

    Les clients de P2P, qui créent des fichiers "vide" de la bonne taille dès le début?

    Par exemple, avec aMule, quand tu télécharges "Internet libre ou Minitel 2.0.avi", de taille 99Mo, il crée un fichier vide "xxx.part" de 99 Mo dès l'instant où il connait la taille, et il remplit ensuite. Ceci afin de réserver l'espace disque.
    T'as plus qu'à tipiaker leur recette ;+)

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Comment font..

      Posté par  . Évalué à 0.

      A priori ils écrivent un gros fichier tout plein de zéros. Aucune chance que ce soient des secteurs continus sur le disque dur.

      Moi je veux bien utiliser un FS qui aie des fonctions spécifiques pour pré-réserver de l'espace continu, pas de souci. La question, c'est comment le faire...

      Léo.

      • [^] # Re: Comment font..

        Posté par  . Évalué à 2.

        Non, il n'y a pas de 0. La taille du fichier et l'occupation sur le disque ne sont pas identiques. J'ai un vague souvenir de le voir, mais je ne sais plus comment.

        Envoyé depuis mon lapin.

        • [^] # Re: Comment font..

          Posté par  . Évalué à 1.

          $ dd if=/dev/zero of=plop bs=1 count=1 seek=1048575
          $ stat -c '%b*%Bo alloués sur disque (vs taille %so)' plop
          8*512o alloués sur disque (vs taille 1048576o)
          $
          ou

          $ mkdir plop
          $ cd plop/
          $ dd if=/dev/zero of=plop bs=1 count=1 seek=1048575
          $ du .
          8,0K .
          $ ls -al .
          total 16K
          drwxr-xr-x 2 bruno bruno 4,0K nov. 28 10:35 .
          drwxr-xr-x 111 bruno bruno 4,0K nov. 28 10:35 ..
          -rw-r--r-- 1 bruno bruno 1M nov. 28 10:35 plop

  • # la ram

    Posté par  . Évalué à 3.

    connais pas le contexte, mais si c'est réellement de la vitesse que tu cherche, tu peux également essayer d'avoir tes fichiers en RAM via un ramdisk.

    • [^] # Re: la ram

      Posté par  . Évalué à 1.

      Bah oui, mais j'en ai pour 40 Go de fichiers. Et ca pourrait monter à 400. Pas possible de tout mettre en RAM, c'est trop cher.

      Condamné à mettre tout en disque ! Evidemment on fait ça sur du Raid1 pour lire plus vite, etc....

      Léo.

      • [^] # Re: la ram

        Posté par  . Évalué à 1.

        40Go par tranche de fichier de 30Kio ?
        je ne sais pas ce que c'est cette appli, mais ca semble coder avec les pieds (enfin je dis ca, je suis pas codeur... et on est encore vendredi)

      • [^] # Re: la ram

        Posté par  . Évalué à 7.

        Mouaip, je connais pas les données du problème, mais ton affaire de fichiers pouvant aller à 30 Ko, pour occuper au total 40 Go c'est peu orthodoxe. Avec ces chiffres, cela te fait plus d'un million de fichier (et 10 million de fichier dans le cas ou tu as 400Go de fichier).

        Vous seriez pas en train de faire le boulot d'une base de données ? Si c'est le cas, cela me paraît être une mauvaise idée car même si de façon générale un modèle géré à la mano est plus rapide, dans le cas où on atteint des volumes pareils, il vaut mieux avoir des gens expérimentés au clavier. Alors qu'avec une BD bien réglé (choix judicieux des clefs, de leur taille, etc), il est difficilement de faire mieux, du moins pour le commun des mortels.

        Par curiosité, tu pourrais nous dire qui en a besoin et pour quel usage ? Aller, je fais le pari que c'est un travail universitaire !

        • [^] # Re: la ram

          Posté par  . Évalué à 3.

          Pourquoi pas de base de données ?

          Déjà faudrait-t-il préciser de quel "type" de base de données a-t-on besoin. Objet, relationnel....

          -On a pas besoin du côté "relationnel" des bases de données que tout le monde connaît. Notre base est plutôt "arborescente".
          -On pourrait se baser sur une bdd arborescente type LDAP, mais semble-t-il qu'il supporte très mal les millions d'entrées... et LDAP est optimisé pour la lecture, nous faisons environ 5 fois plus d'écritures que de lectures.
          -MySQL commence à pêcher quand on arrive à 80-100M d'entrées dans une table, même avec des indexes bien 'pensés', surtout lorsque l'on ajoute/supprime fréquemment des entrées. Les DELETE ou INSERT prennent beaucoup, beaucoup de temps. Même avec une grosse machine. Et on n'a pas de sous pour acheter du Oracle.
          -On développe super bien, on est des kadors. Si, si, je te jure !
          -En fait... c'en est une, de base de données, mais sous forme de fichiers. Dans la 'définition', ça colle. Ca nous suffit, en fait. Nous sommes partisans du principe KISS (Keep It Simple & Stupid).

          Et ... non, ce n'est pas universitaire. Raté.

          • [^] # bsd DB

            Posté par  (site web personnel) . Évalué à 1.

            et avec berkely db ? puisque y'a pas besoin du côté relationel.
            et pourquoi pas compressé les données dans la base avec un algo rapide comme lzo1.
            c'est ce que j'ai essayé pour trouver une autre bd pour pacman.

            pacman utilise pour l'instant des fichiers aussi. KISS ! ça marche bien et c'est rapide. sauf que c'est lent la 1ère fois qu'il faut parser tous les fichiers. mais bon, on s'y fait. c'est toujours plus rapide que d'autres gestionnaire de paquet ;-)

            • [^] # Re: bsd DB

              Posté par  (site web personnel) . Évalué à 3.

              Sinon, il y a les bases alternatives, CouchDB pour une vision plus neuve ou HDF5 pour une vision plus scientifique. Ce dernier mériterait d'être plus connu, mais encore une fois, tout dépend de la problématique.

            • [^] # Re: bsd DB

              Posté par  . Évalué à 2.

              Oui, on aurait pu, mais on a eu un peu peur de faire manger des gigas et des gigas à BDB.

              On pense à compresser les données "à la volée" dans le futur pour gagner un peu d'espace, je regarderai lzo1 que je ne connaissais pas (merci!).

  • # pas grand chose...

    Posté par  (site web personnel) . Évalué à 5.

    J'y connais pas grand chose mais... si tu augmente la taille des blocks de ton fs vers 30k? ... ça perd un peu de place si tu dois faire un fichier de 31k mais bon...

    • [^] # Re: pas grand chose...

      Posté par  . Évalué à 3.

      Effectivement, j'y avais pas pensé, et ça aurait été de la belle optimisation.

      Mais en fait, Ext3 et ReiserFS ne permettent respectivement que des tailles de 4096 et 8192 o au maximum (damned!). Et ce sont les deux seuls FS dont on a la maîtrise.

      Merci en tout cas pour ton commentaire.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.