Journal Fait n°1 : Linux n'est pas sujet à la fragmentation...

Posté par  .
Étiquettes : aucune
0
7
déc.
2005
Un mythe s'effondre, c'est faux !

J'ai une partition formatée en ext3fs avec 21% de « non-contiguous blocks », et qui du coup se traîne à 25% de ses performances habituelles, qui se sont écroulées à un vulgaire 2,5 Mo/s pour du UDMA100 bien configuré (ie DMA activé, etc.)

Mes recherches sur google m'ont prouvé que la fragmentation existe bel et bien sur les différents systèmes de fichiers existants sous Linux, il existe même des utilitaires, tels la commande defrag, pour pallier au problème.

Apparemment, la fragmentation touche principalement l'une de mes partitions sur laquelle aMule écrivait ses données en permanence, et qui était quasi-pleine ces derniers temps. Mais une autre partition qui ne servait à rien d'autre si ce n'est y stocker de gros fichiers de temps en temps, et qui affiche elle aussi pas loin de 20% de non-contiguous blocks. Il est vrai qu'elle aussi avait tendance à être bien pleine.

Cela dit, la partition qui semble être la moins fragmentée, mon /home, affiche quand même pas loin de 5% de blocks non-contigus. À comparer aux 2 ou 3% de taux de fragmentation que j'ai l'habitude d'avoir sur mes PC sous Windows XP (sur lesquels je n'ai jamais défragmenté quoi que ce soit).

Il semblerait cependant que ce problème de fragmentation n'affecte principalement que les disques durs presque pleins (en général, en dessous de 80% de remplissage, pas de problème). Le problème, c'est qu'une fois fragmenté, il n'y a quasiment aucune solution pour s'en sortir ! Ainsi, on peut lire un conseil sur newsforge qui consiste à sauvegarder l'intégralité de la partition, la reformater, et y redescendre ensuite les fichiers sauvegardés. Sacrément long, et pas très logique.

Voilà, c'était la minute coup de gueule, parce que je vais probablement devoir réinstaller ma machine, qui du fait de cette fragmentation, de la lenteur du système engendré, et autre, m'occasionne bien des soucis. Du coup, je vais en profiter pour essayer autre chose qu'ext3fs, vu que je râlais dessus dans un autre journal, suite à de multiples pertes de données avec.

Au passage, mon petit dossier comparatif sur quelques distributions linux et Windows XP avance, publication prochaine en vue ! ;-)

Bonne nuit !

  • # Mouah

    Posté par  . Évalué à 10.

    Télécharge tes backups de distribution linux sur lip6 plutot qu'*Mule, ça ira plus vite.

  • # Pas besoin de réinstaller...

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

    Bon deja, c'est pas nouveau, tu as l'air de découvrir ca, mais c'est pas la premiere fois qu'on aborde le sujet ici. C'est un truc que les admins connaissent bien, c'est toujours marrant d'essayer de se debrouiller avec des disques qui se trainent car presque pleins et super fragmentés :-)

    Ca dépend evidemment beaucoup du filesystem, et de l'utilisation que tu en as (d'ou l'interet de séparer ses partitions selon ce que tu fais dessus par exemple). Ré-installer me semble un peu beaucoup, tu as divers outils pour t'en sortir (et sauvegarder l'ensemble pour le remettre est au contraire tres logique, sinon, ya aussi convertfs par exemple pour en profiter pour passer a autre chose). Si tu veux des détails sur l'histoire, et une solution potentielle, c'est orienté reiserfs mais tu peux, tu dois lire meme:
    http://www.00f.net/php/show-article.php/fragmentation_of_uni(...)

  • # Fait n˚2 : être un peu plus précis...

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Hello !

    La partition /home (ext3) de mon laptop (35Go) est pleine a 92%, j'ai 2.1% de "non-contigous blocks", alors que cette partition travaille beaucoup et gère des fichiers plus gros que l'espace disque restant. La performance du système de fichier variant suivant la taille des fichiers, je mesure la performance par la vitesse de lecture par hdparm. Et j'observe 30Mo/s. Je précise que c'est un disque 5400rpm de laptop. Cette machine a été installée sous Fedora Core 4 il y a 6 mois sans réglage particulier.

    La partition /home (ext3 aussi) d'un des serveurs que j'ai en exploitation est pleine à 92% elle aussi, pour une taille totale de 459Go, avec des fichiers de plus de 10Go. J'ai 1.0% de non-contigous blocks là aussi. et une vitesse de 81Mo/s en lecture (hdparm tjrs). Cette machine est en production depuis 2 ans et demi environ, allumée 24h/24h. Pas de réglage particulier particulier non plus, tout tourne sous Fedora Core 1.

    Donc tu as raison : tu as un souci. Mais je ne crois pas que ce sois linux, mais peut-être plutôt un problème spécifique à ton système, ou alors simplement une conséquence du fait que tu as une multitude de petit fichiers sur cette partition.
    Au choix :
    - tu continues tes calomnies ?
    - tu attends des conseils pour résoudre ton problème, et si oui, les premières questions sont "quelle format pour ta partition ?" puis "comment as-tu mesuré le 25% de ses perfs et le 2.5Mo/s dont tu parles" ?

    Ce que tu dis ressemble à quelqu'un qui découvre linux et qui lui tape dessus sans savoir de quoi il parle. Je ne dit pas que c'est le cas, mais que ca y ressemble :)

  • # Un mythe, vraiment ?

    Posté par  . Évalué à 10.

    Je crois que personne connaissant tant soit peu les systèmes d'exploitation (SE) et plus spécialement l'implémentation des systèmes de fichiers (SF) n'a jamais dit que la fragmentation n'existe pas, que ce soit sous Linux ou tout autre système dit "moderne".

    Pour retrouver des SF n'ayant aucune fragmentation, il faut revenir aux années 1970 et au SE OS/VS d'IBM. Ce SF utilisait des unités d'allocations de taille et d'implantation physique fixes (allocation dite contiguëe) déterminées à la création du fichier. Mais quelle joie pour l'administrateur système de savoir où implanter un fichier (en terme de cylindre-piste) dans une installation qui pouvait comporter plusieurs milliers de fichier ! Et cette absence de fragmentation se payait par la nécessité de connaître, au moment de la création du fichier, la taille maximum que celui-ci pouvait atteindre. On imagine aisément le gaspillage de place disque, surtout à l'époque où une capacité de 128 Mo sur disque était considérée comme le summum du confort. Mais il y avait, pour les grandes installations, des batteries impressionnantes d'unités de disques.

    S'il est vrai que la quasi totalité des SF actuels (à ma connaissance et en dehors des SF temps réels devant répondre à des spécifications rigoureuses en terme de temps d'accès disque) travaillent en allocation chaînée (FAT en est une variante dégénérée) ou en allocation indexée (cas de Linux). Ces types d'allocations souffrent, intrinséquement, de fragmentation.


    Maintenant reste à voir l'effet de cette fragmentation sur l'efficacité du traitement:

    - Sous Windows (et ses dérivés / clones), les lectures / écritures se font selon l'organisation LOGIQUE des données, indépendamment de leurs positions PHYSIQUES sur le disque. Dès lors, il s'ensuit de nombreux déplacement des têtes d'accès en cas d'un taux de fragmentation relativement grand.
    Il existe bien un tampon, dont on peut se demander à quoi il sert d'ailleurs. D'ailleurs, si je me souviens bien (mes dernières utilisation de Windows remontent à plusieurs années), si l'on augmente la taille du tampon a cela d'une certaine limite, les performances diminuent, un effet "marrant" qui fait se "bidonner" les spécialiste des SE.

    - Sous Linux (Unix et ses dérivés / clones), les lectures / écritures se font selon l'organisation PHYSIQUE des données à partir du tampon. Dès lors, les déplacement des têtes d'accès sont limités drastiquement.
    C'est, en fait, un peu plus complexe avec les disques de grande capacité. En effet, à cause de certaines restrictions du BIOS (adresse en cyl-track-sector avec nombre de bits limités), la géométrie physique que "voit" le SE n'a que peut de rapport avec la géométrie physique effective des disques et cela tant que l'adressage se fera en termes absolus (cyl-track-sector) et non pas en terme relatifs (origine+déplacement notés en nombre de secteurs ou, mieux, en nombre de blocs de taille modifiable).
    Au surplus, sous Linux, l'allocation d'un nouveau bloc disque à un fichier se fait selon un algorithme qui tend à minimiser la distance physique de ce bloc des autres blocs du fichier.
    Par contre, il est parfaitement vrai que cet algorithme perd de son efficacité avec l'augmentation du taux de remplissage du disque (plus difficile de trouver un bloc, ou un ensemble de blocs, contiguës !).
    Si, par ailleurs, la taille du tampon est réduite, l'optimisation des déplacements se fera sur un nombre de blocs plus petit et sera par conséquent moins efficace. À la limite, pour un tampon d'un seul bloc, on se trouve ramené au cas de la mise à jour en ordre logique.
    Sous Linux, la taille du tampon est automatiquement ajustée en fonction des processus en mémoire.


    Donc, sous Linux, mémoire physique relativement faible, nombreux processus actifs, disque presque plein se conjuguent pour diminuer l'efficacité. Mais, amha, ce sont des conditions limites, qui impliquent (si les moyens financiers le permettent) achat de mémoire et / ou de disques.
    Et se sont des conditions qui, sous Windows, plantent totalement le système.

  • # Autre chose, oui mais quoi ?

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

    Et que conseillerais-tu à la place de ext3 qui soit équivalent ou meilleur en performance ?

    parcqu'il me semble me rapeller (mais peut-être me gourais-je) certain bench ou ext3 étais clairement le plus rapide en fait.

    AU fait quelqu'un sait si le "nouveau" ZFS de Sun sera supporté sous GNU/Linux ?

  • # Avant toute chose, il faut se renseigner...

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

    Tu ne sembles pas vraiment savoir ce qui crée de la fragmentation sur un disque dur. Il serait sans doute que tu te renseignes avant d'écrire un journal. A moins que celui-ci ne soit là que pour critiquer (voir, troller)...

    La raison pour laquelle les partitions ext2/3 ne fragmentent pas, ou peu, c'est qu'elles gardent en mémoire sur le disque dur, une table indiquant la taille des blocs libres. Ainsi, lorsque l'OS veut écrire un fichier, il choisit le bloc de la plus petite taille possible et qui peut contenir le fichier en un seul morceau. En comparaison, les FAT12/16/32 de Windows n'ont pas ce type de mécanisme (et pour NTFS, je ne sais pas).

    Avec un DD presque plein en permanence, surtout contenant des fichiers de grosse taille (j'imagine que ton aMule ne fait que télécharger des images ISO de distributions Linux, au format CD ou DVD...), il ne peut rester comme place sur le disque que des blocs éparses. Donc forcément le FS se fragmente lorsque tu veux rajouter des données, car il ne peut pas trouver un emplacement continue de 700Mo ou 4.7Go.

    De plus, aMule (et les autres softs de P2P) amplifie le phénomène de fragmentation, car ils stockent initialement les fichiers téléchargés sous la forme de petits blocs, téléchargés indépendament sur Internet (je suppose par la que tu commences toujours par télécharger des images ISO de distributions Linux, et que tu n'en mets donc pas "spontanement" en partage). Si tu télécharges plusieurs fichiers en parallèle, tu aura donc une partie de ton DD qui sera composé de multiples petits fichiers temporaires
    Une fois que qu'une image ISO sera coomplètement téléchargée, *Mule recréera un fichier unique, là où il y a de la place. Et comme ton DD est plein, ce sera à l'emplacement d'anciens petits blocs temporaires

    Si tu utilisais un *Mule sous Windows, tu verrais exactement le même phénomène.

    Quand à ceci :
    Ainsi, on peut lire un conseil sur newsforge qui consiste à sauvegarder l'intégralité de la partition, la reformater, et y redescendre ensuite les fichiers sauvegardés. Sacrément long, et pas très logique
    Le "pas très logique" confirme bien que tu ne comprends pas le phénomène de fragmentation. C'est pourtant le seul moyen de ne pas fragmenter un DD, lorsque l'on n'utilise pas un soft qui manipule directement le FS au niveau des blocs (donc un soft de defragmentation)

    Au passage, mon petit dossier comparatif sur quelques distributions linux et Windows XP avance, publication prochaine en vue ! ;-)
    Au vu de tes journaux, et de ton niveau de connaissances techniques de Linux (je ne parle pas d'experiences, ou d'experimentations), les trollometres vont exploser...

    • [^] # Re: Avant toute chose, il faut se renseigner...

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


      De plus, aMule (et les autres softs de P2P) amplifie le phénomène de fragmentation, car ils stockent initialement les fichiers téléchargés sous la forme de petits blocs, téléchargés indépendament sur Internet


      Euh, je connais pas bien le fonctionnement exact des logiciels qui utilisent le réseau edonkey, ni trop bittorrent, mais justement, il me semble que les 2 créent initialement le fichier complet, mais vide, et le remplisse petit à petit.

      Au contraire de WhiteWater, par exemple, qui stocke chaque petit bout, et qui reconstruit le fichier après.

      • [^] # Re: Avant toute chose, il faut se renseigner...

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

        Les softs de p2p allouent en général un fichier vide, mais "sparse", c'est à dire que l'espace disque n'est pas encore occupé. Après, c'est au filesystem de se débrouiller avec.

      • [^] # Re: Avant toute chose, il faut se renseigner...

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

        Si je ne me trompe pas, avec aMule par exemple (et par défaut car peut-être que ce comportement est paramétrable) si tu télécharges un fichier disons de 700MB, il va créer un fichier dans le répertoire Temp qui correspondra grosso modo au volume de données deja téléchargées mais pas à la taille finale du fichier.

        Une fois le fichier récupéré, il mouline pour remettre tous les morceaux dans le bon ordre est crée le fichier définitif dans Incoming.

        Une bonne grosse source de fragmentation ça :). D'où l'intérêt, AMHA, d'avoir une partoche spécialement dédiée à *Mule (avec un système basé sur LVM ou équivalent, c'est très simple à faire après coup).

      • [^] # Re: Avant toute chose, il faut se renseigner...

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

        Je confirme, création d'un fichier vide de la taille du fichier en téléchargement dès le debut de celui-ci.

        • [^] # Re: Avant toute chose, il faut se renseigner...

          Posté par  . Évalué à 4.

          j'infirme , cela dépend principalement du client.
          Exemple avec azureus , peut choisir quel type d'allocation on veut :
          allocation dynamique (un fichier qui augmente au fur et a mesure de taille)
          une allocation statique( avec une intialisation en le remplissan de 0 meme si on veut éviter la fragmentation)...

      • [^] # Re: Avant toute chose, il faut se renseigner...

        Posté par  . Évalué à 2.

        il me semble que les 2 créent initialement le fichier complet, mais vide, et le remplisse petit à petit.


        c'est vrai que c'est ennuyeux cela, lorsque par exemple on télécharge par P2P en même temps la dernière Fedora, la dernière Knoppix, Ubuntu, SuSE, les 9 iso de Debian, les DVD de Solaris, les iso de Slackware, Mandriva etc.... cela en fait un paquet de place alloué sur le système rien que pour ces films iso...

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Avant toute chose, il faut se renseigner...

        Posté par  . Évalué à 2.

        le pb de ces logiciels c'est qu'il remplisse plus ou moins plusieurs gros fichiers en meme temps.

        Il y a un test marrant a faire avec dd :
        lancer 5/10 dd if=/dev/urandom of=$i count=$x en parallele, puis regarder le taux de fragmentation...

    • [^] # Re: Avant toute chose, il faut se renseigner...

      Posté par  . Évalué à 3.

      Ainsi, lorsque l'OS veut écrire un fichier, il choisit le bloc de la plus petite taille possible et qui peut contenir le fichier en un seul morceau


      Il me semble que cette stratégie (best fit) est au contraire très mauvaise, car elle laisse des tous petits blocs si le fichier est trop petit pour remplir le bloc libre.

      La meilleure stratégie si je me souviens bien de mes cours était au contraire "worst fit" (on choisit le plus grand bloc libre et on y met le fichier au bout).

      Après il y a surement des trucs plus élaborés, mais worst-fit était meilleure que best-fit.

      • [^] # Re: Avant toute chose, il faut se renseigner...

        Posté par  . Évalué à 3.

        avec des noms pareils, j'aurais juré le contraire !

        • [^] # Re: Avant toute chose, il faut se renseigner...

          Posté par  . Évalué à 1.

          Je confirme qu'il faut se renseigné !
          Sous un SE il faut avoir conscience qu'il faut agir des qu'il ne reste plus que 20% d'espace libre sur une partition qui a tendance à se remplire ;-)
          La fragmentation et lié au manque d'espace dans 90% des cas et celui-ci doit s'anticipé !

          J'ai eu ce problème une fois plus d'espace sur une partoche

          solution :

          Ajout d'un disque : ce coup si, j'ai fait un LVM (taille variable) sur ce disque
          redémarré en mode single user copié les fichiers sur la nouvelle partition
          modification du fstab pour monter la nouvelle partoche à la place de l'ancienne

          et c'est reparti ! J'avais mal évalué la taille de cette partition.
          elle hébergé les mailbox de mon serveur de messagerie
          (certains utlisateurs n'allé jamais retirer leur mail, soit plus de 100000 mails
          et allé supprimé 15000 mails sur un compte malgrès une liaison 100Mb devien un parcours du combattant.
          sur un compte je l'ai tenté celà à pris 1 journée
          (temps de rappatriment sur outlook express, de suppression et vidage corbeille)

  • # apt-get install defrag

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

    oui oui, defrag existe sous linux.
    ext1/ext2 (donc ext3) et minix sont supportés.

    si tu n'as pas debian ou ubuntu, va ici:
    http://linux.maruhn.com/sec/defrag.html

    ceci dit, je n'ai pas testé, donclis la man page et vérifie si tu doit sauvegarder tes données..

    Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie

  • # Trop d'extinctions sauvages ?

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

    Peut-être que je me trompe et que ça n'a rien à voir, mais il me semble avoir remarqué que pourcentage de blocks non-contigus augmentait souvent suite à des extinctions sauvages de ma machine. Si c'est une explication valable (?), alors peut-être est-ce pareil chez toi ?

  • # Complément d'info?

    Posté par  . Évalué à 2.

    J'ai lu les commentaires un peu rapidement. Il se peut
    donc que je répète ce qui a déjà été dis.

    Avec une partition FAT, quand tu écris un fichier, il est collé au
    le plus possible au début du disque. Résultat, même si tu
    utilise 10% de ton disque et qu'il y a plein de place, si tu as plein
    de petits trous au début de ton disque, ça fragmente pour
    remplir tous les trous.

    La plupart des système de fichiers un minimum raisonnables
    commencent par essayer de caser le fichier sans essayer de
    le frangmenter, ce qui semble quand même raisonnable.

    J'avais lu un article qui démontrait (avec des vrais maths et tout
    et tout) que si un disque était rempli au plus aux 2/3 et que les
    fichiers avaient une taille « raisonnable » (je ne me souviens plus
    des détails), alors le disque avait tendance à ce défragmenter
    tout seul. En gros il se peux qu'on fragmente mais ça n'arrive pas
    trop souvent et comme on efface aussi des fichiers, on efface
    aussi des fichiers fragmentés.

    Donc, effectivement, si tu remplis ton disque à 99%, alors ça va
    fragmenter. Ce n'est pas pour autant une raison pour se dire,
    puisse que de toute façon, ça fragmente, je reste avec mes
    partitions FAT.

  • # Comment ?

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

    C'est une question que j'ai souvent posé sans jamais trouver personne qui puisse me répondre : "comment faites-vous pour connaître le degré de fragmentation d'une partition ?"

    Parce qu'un ext3fsck/reiserfsck/... ne donne pas cette info

    • [^] # Re: Comment ?

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

      e2fsck avec le parametre -v chez moi ....

    • [^] # Re: Comment ?

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

      fsck -f /dev/blabla ne te donne pas l'info ? Ca fait longtemps que j'ai pas essayé (et ne pas utiliser fsck est plutot bon signe, je croise les doigts :)

    • [^] # Re: Comment ?

      Posté par  . Évalué à 1.

      Tu peux utiliser filefrag aussi qui te donne carrement une précision au niveau fichier.

      http://www.die.net/doc/linux/man/man8/filefrag.8.html

      • [^] # Re: Comment ?

        Posté par  . Évalué à 4.

        Juste pour préciser parceque je me suis posé la question, ce que rapporte filefrag c'est le nombre de fois où il faut aller chercher un block à un nouvel emplacement (donc pas juste après le précédent). Sur un fichier non fragmenté, comme il l'indique dans ce qu'il affiche, ça ferait "1".

        Ce nombre (disons N) est donc à comparer avec le nombre des blocks occupés par le fichier (disons M). Le ratio de fragmentation du fichier est donc à la louche un truc du genre (N-1)/(M-1).

        D'où le petit script suivant pour faire plus joli :

        % cat fragmentation.sh
        #!/bin/bash
        filesize=$(ls -s --block-size=4KB "${1}" | cut -d\ -f1)
        if [[ ${filesize} -gt 1 ]] ; then
        extents=$(/sbin/filefrag "${1}" | sed -n 's/.*: \([0-9]\+\) extents.*/\1/p')
        fragmentation=$(bc <<<"scale=1;100*(${extents}-1)/${filesize}" )
        else
        # pas de division par zero...
        extents=${filesize}
        fragmentation=0
        fi
        echo "${1}: ${filesize} blocks, ${extents} extents, ${fragmentation}% fragmentation"

        % sudo ./fragmentation.sh linux-2.6.14.tar.bz2
        linux-2.6.14.tar.bz2: 9805 blocks, 492 extents, 5.0% fragmentation


        Enfin, en espérant que j'ai pas tout compris de travers et que mon raisonnement n'est pas foireux :)

        • [^] # Re: Comment ?

          Posté par  . Évalué à 2.

          Ah mince, dans le extents=$(...), dans l'expression sed, faut virer le "s" à extents, parceque y'a a pas si le résultat est "1":

          extents=$(/sbin/filefrag "${1}" | sed -n 's/.*: \([0-9]\+\) extent.*/\1/p')

  • # Réponse groupée

    Posté par  . Évalué à 2.

    Pour faire plus simple, je vais faire uen réponse groupée à pas mal de message de ce journal. :-)

    Bon deja, c'est pas nouveau, tu as l'air de découvrir ca, mais c'est pas la premiere fois qu'on aborde le sujet ici. C'est un truc que les admins connaissent bien, c'est toujours marrant d'essayer de se debrouiller avec des disques qui se trainent car presque pleins et super fragmentés :-)


    Effectivement, je découvre :-)
    Jusqu'à présent, je m'étais fié à un article de Roberto di Cosmo qui affirmait plus ou moins que sous Linux, la fragmentation n'existait pas.

    Ré-installer me semble un peu beaucoup, tu as divers outils pour t'en sortir (et sauvegarder l'ensemble pour le remettre est au contraire tres logique, sinon, ya aussi convertfs par exemple pour en profiter pour passer a autre chose).


    La réinstallation est de toutes façons rendu nécessaire du fait que je traîne ma cooker depuis un bon moment, et qu'elle commence à craquer de partout ;-)

    Pour le côté logique, certes, ça l'est, puisque la copie de fichier se fait de manière séquentielle et linéaire, cela va assurément copier les fichiers sans fragmentation. Mais quel boulot !

    La partition /home (ext3) de mon laptop (35Go) est pleine a 92%, j'ai 2.1% de "non-contigous blocks", alors que cette partition travaille beaucoup et gère des fichiers plus gros que l'espace disque restant. La performance du système de fichier variant suivant la taille des fichiers, je mesure la performance par la vitesse de lecture par hdparm. Et j'observe 30Mo/s.
    [...]
    La partition /home (ext3 aussi) d'un des serveurs que j'ai en exploitation est pleine à 92% elle aussi, pour une taille totale de 459Go, avec des fichiers de plus de 10Go. J'ai 1.0% de non-contigous blocks là aussi. et une vitesse de 81Mo/s en lecture (hdparm tjrs).


    Comme signalé dans les commentaires à ta réponse, hdparm ne passe pas par le système de fichiers pour faire ses mesures. Personnellement, hdparm continue de m'annoncer un débit de 40 Mo/s, alors que sur copie de fichiers, ce débit est de l'ordre de 2,5 Mo/s à 5 Mo/s (et jusqu'à récemment encore, lorsque le disque était moins fragmenté, il était encore de 10 Mo/s). Je précise que le disque est sain, cela a été longuement vérifié.

    Donc tu as raison : tu as un souci. Mais je ne crois pas que ce sois linux, mais peut-être plutôt un problème spécifique à ton système, ou alors simplement une conséquence du fait que tu as une multitude de petit fichiers sur cette partition.


    J'aurais plutôt une multitude de gros fichiers sur cette partition.

    Au choix :
    - tu continues tes calomnies ?


    Tout de suite les gros mots, il ne faut pas s'emporter parce que je souligne un fait, hein :-)

    - tu attends des conseils pour résoudre ton problème, et si oui, les premières questions sont "quelle format pour ta partition ?" puis "comment as-tu mesuré le 25% de ses perfs et le 2.5Mo/s dont tu parles" ?


    La partition est formatée en ext3fs, et avait tendance à n'avoir que quelques Mo de libre ces derniers temps (parfois moins d'1 Mo). Les 25% et 2,5 Mo sont le résultat d'une comparaison avec le système il y a encore quelques semaines et aujourd'hui, sur copie de fichiers (puisque je suis en train de faire mes sauvegardes intégrales, je m'en rend bien compte).

    Ce que tu dis ressemble à quelqu'un qui découvre linux et qui lui tape dessus sans savoir de quoi il parle. Je ne dit pas que c'est le cas, mais que ca y ressemble :)


    Effectivement, je découvre encore Linux, bien que cela fasse plus de 3 ans que je l'utilise exclusivement sur ma machine principale. Je dirais même que Linux est pour moi une découverte perpétuelle depuis que je l'utilise. Et certes, mes connaissances Linux ne sont pas encore à la hauteur de celles que j'ai sous Windows, bien que cela soit difficilement mesurable, mais on ne peut pas non plus être expert partout. ;-)

    Je crois que personne connaissant tant soit peu les systèmes d'exploitation (SE) et plus spécialement l'implémentation des systèmes de fichiers (SF) n'a jamais dit que la fragmentation n'existe pas, que ce soit sous Linux ou tout autre système dit "moderne".


    Roberto di Cosmo si, il me semble.

    Donc, sous Linux, mémoire physique relativement faible, nombreux processus actifs, disque presque plein se conjuguent pour diminuer l'efficacité. Mais, amha, ce sont des conditions limites, qui impliquent (si les moyens financiers le permettent) achat de mémoire et / ou de disques.
    Et se sont des conditions qui, sous Windows, plantent totalement le système.


    C'est un peu ce que j'ai constaté, et l'achat d'un nouveau disque dur est en prévision. Sinon, effectivement, un Windows sur un disque surchargé ne s'en sort pas mieux.

    Et que conseillerais-tu à la place de ext3 qui soit équivalent ou meilleur en performance ?


    Personnellement, j'envisage Reiserfs, mais ça n'engage que moi et n'est basé sur rien de concrêt pour l'instant.

    parcqu'il me semble me rapeller (mais peut-être me gourais-je) certain bench ou ext3 étais clairement le plus rapide en fait.


    Le problème d'un benchmark, c'est qu'il ne mesure pas tout, mais juste une chose, dans des conditions particulières.

    Tu ne sembles pas vraiment savoir ce qui crée de la fragmentation sur un disque dur. Il serait sans doute que tu te renseignes avant d'écrire un journal. A moins que celui-ci ne soit là que pour critiquer (voir, troller)...


    C'est d'ailleurs pour cela que je suis bête, et que j'ai émis les hypothèses de cette fragmentation dans mon journal. :-)

    Avec un DD presque plein en permanence, surtout contenant des fichiers de grosse taille (j'imagine que ton aMule ne fait que télécharger des images ISO de distributions Linux, au format CD ou DVD...), il ne peut rester comme place sur le disque que des blocs éparses. Donc forcément le FS se fragmente lorsque tu veux rajouter des données, car il ne peut pas trouver un emplacement continue de 700Mo ou 4.7Go.


    Ben figure toi que le fait que j'ai précisé que la partition était pleine et qu'un aMule tournait dessus n'était pas innocent hein... C'était justement pour montrer dans quel cas de figure cela c'était produit, et donner, à mon avis, la raison principale de cet état de fait.

    Ainsi, on peut lire un conseil sur newsforge qui consiste à sauvegarder l'intégralité de la partition, la reformater, et y redescendre ensuite les fichiers sauvegardés. Sacrément long, et pas très logique
    Le "pas très logique" confirme bien que tu ne comprends pas le phénomène de fragmentation. C'est pourtant le seul moyen de ne pas fragmenter un DD, lorsque l'on n'utilise pas un soft qui manipule directement le FS au niveau des blocs (donc un soft de defragmentation)


    Contrairement à ce que tu as l'air de croire, j'ai parfaitement compris la « logique » derrière la chose. Ce que je ne trouve pas très logique, c'est d'être obligé de faire ce genre de manips à la main, sans avoir un logiciel qui vient réorganiser les fichiers sur le disque. La commande defrag, que j'ai utilisée sur quelques fichiers, m'a semblé peu fiable, ne serait-ce que parce qu'elle semble ne pas accepter les fichiers contenant des caractères accentués dans leur nom.

    Au passage, mon petit dossier comparatif sur quelques distributions linux et Windows XP avance, publication prochaine en vue ! ;-)
    Au vu de tes journaux, et de ton niveau de connaissances techniques de Linux (je ne parle pas d'experiences, ou d'experimentations), les trollometres vont exploser...


    Ça tombe bien au contraire, puisque le test concerne la prise en main par des débutants. Sinon, ce n'est pas moi qui ai noté les différentes distributions, mais 2 « assistantes sexys » ;-)

    • [^] # Re: Réponse groupée

      Posté par  . Évalué à 4.

      Jusqu'à présent, je m'étais fié à un article de Roberto di Cosmo qui affirmait plus ou moins que sous Linux, la fragmentation n'existait pas.

      Est ce que tu parle de cet article là?
      --->
      http://membres.lycos.fr/conjonction/absurde/piegecyb.htm

      Car c'est clairement un article de vulgarisation qui ne rentre pas dans tous les details. Et pourtant meme avec l'analogie de la secretaire tu te doute bien qu'avec un disque plein à 90% tu sera obligé de ranger les gros fichiers en divers endroit!

    • [^] # Re: Réponse groupée

      Posté par  . Évalué à 1.


      Contrairement à ce que tu as l'air de croire, j'ai parfaitement compris la « logique » derrière la chose. Ce que je ne trouve pas très logique, c'est d'être obligé de faire ce genre de manips à la main, sans avoir un logiciel qui vient réorganiser les fichiers sur le disque. La commande defrag, que j'ai utilisée sur quelques fichiers, m'a semblé peu fiable, ne serait-ce que parce qu'elle semble ne pas accepter les fichiers contenant des caractères accentués dans leur nom.

      Il me semble que ce n'est pas très compliqué de faire un petit script appelé, comme par hasard, defrag du genre (en admettant, par exemple que ta partition à défragmenter soit sur /dev/hda4 et que tu veuille la transformer en Reiser FS):

      cd /répertoire_de_ma_partition_merdique
      cp -rdpf * /répertoire_d'une_partition_assez_grande
      umount /répertoire_de_ma_partition_merdique
      mkfs -t reiserfs /dev/hda4
      mount /dev/hda4 /répertoire_de_ma_partition_merdique
      cd /répertoire_d'une_partition_assez_grande
      cp -rdpf * /répertoire_de_ma_partition_merdique

      Aucune garantie quand à d'éventuelles erreurs dans le script ci-dessus, donné juste comme exemple de ce que l'on peut faire.

      Bien sûr, à exécuter sous root, alors essaie de faire attention à ce que tu fais.



      Si tu parles de cet article:

      Effectivement, je découvre :-)
      Jusqu'à présent, je m'étais fié à un article de Roberto di Cosmo qui affirmait plus ou moins que sous Linux, la fragmentation n'existait pas.


      Moi je lis:

      ... le disque est toujours très peu fragmenté et plus on l'utilise ...


      Comme quoi di Cosmo semble être d'accord avec la plupart des intervenants (lol), le contraire m'aurait surpris. Linux minimise la fragmentation mais ne la supprime pas. La fragmentation tu l'auras toujours, comme je te l'ai dit plus haut, elle est intrinsèque aux systèmes de fichiers modernes. Mais des algorithmes un peu plus futés que d'autres en diminue grandement l'impact.


      *humour*
      Alors un conseil, puisque tu vas sortir pour acheter un HD, profites-en pour passer chez ton opticien, tu semble avoir besoin de lunettes pour lire convenablement les textes.
      */humour*

    • [^] # Re: Réponse groupée

      Posté par  . Évalué à 3.

      Sinon, ce n'est pas moi qui ai noté les différentes distributions, mais 2 « assistantes sexys » ;-)

      Il n'y en aurait pas une qui s'appellerait Marie, par hasard ? ;-)

      (NB: ceci est une private joke pour les moules attentives :-)

      • [^] # Re: Réponse groupée

        Posté par  . Évalué à 3.

        Tu as gagné ;-)
        Elle tient le rôle de la débutante totale à merveille d'ailleurs.

    • [^] # Re: Réponse groupée

      Posté par  . Évalué à 3.

      Heu oui mais tu n'a pas répondu à l'essentiel:

      On explique que certains logiciels de p2p (mldonkey fait ça, je ne sait pas trop pour aMule) font volontairement des gros fichiers "à trous" (aka "fragmentation").

      Alors moi je trouve très bien que Linux (comme les autres systèmes POSIX en fait) permette de fseek()er comme un salop après la fin d'un fichier lorsque je (ou une appli) le souhaite, et surtout qu'il ne "defragmente" dans mon dos.

      On dit souvent que Linux (sur ext3) (et les *BSD sur ffs et ufs2 d'ailleur) ne fragmente pas trop: il faut comprendre qu'il sait bien gérer les fichiers tout seul et se debrouille pour les aranger proprement, lorsqu'on ne lui donne pas de contre-directives à ce sujet.
      Celà étant posé, il n'empêche pas la fragmentation intentionelle, volontaire, décidée par l'utilisateur, car elle peut être justifiée.

      Bref, la conclusion de tout ce fil, c'est : "les applis de p2p sont de grosses cochonnes avides de ressources", rien de neuf, et pas de quoi fouetter un chat ...

  • # Mouahaha

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

    >2 ou 3% de taux de fragmentation que j'ai l'habitude d'avoir sur mes PC sous
    >Windows XP

    http://hibbert.univ-lille3.fr/~cbellegarde/Windows.png

    Bah, ca doit être le 10 ieme serveur Windows que je trouve dans cet état la, alors me dire que du à 2 à 3 % de fichier fragmenté sous Windows Xp, ca me fait bien rire ;) Surtout quand Microsoft avoue que Windows fait acutellement n'importe quoi et que seul Windows Vista aura un comportement correcte vis à vis de la fragmentation(en l'évitant comme font tous les autres OS).

    Enfin, un Windows qui fait serveur de fichier/auth, tu peux être sur que si tu ne défragmente pas régulierement, tu finieras par avoir un FS comme celui du shot et que à ce moment la, meme en mode sans echec, plus moyen de défragmenter...

  • # Ext3 + reservation

    Posté par  . Évalué à 7.

    Depuis le 2.6.10 (environ :-), un patch très interessant inclu dans le kernel vanilla. l'ext3 reservation autrement appelé "preallocation".

    Une option de montage "mount -o reservation" et zou c'est activé.

    Ça permet en fait de preallouer une certaine quantité de memoire et de donc de block contigus lors de l'ecriture des données (même très petites).

    En conséquence, les fragments de fichiers, si fragmentation il y a, sont de tailles suffisament conséquentes pour ne pas trop pénaliser les performances du système de fichier (y compris dans le cas de lectures /ecritures parallèles!!)

    http://people.redhat.com/arjanv/reservations.png

    A suivre de près aussi les travaux de Mingming Cao:
    http://www.bullopensource.org/ext4/ext4_test_plan.html

  • # hdparm+copie

    Posté par  . Évalué à 3.

    1. Hdparm ne donne que les performances du disque en début de disque (chez
    moi, ça donne 60 MB/sec).

    2. En fin de disque, il faut +/- diviser les performances par 2 (chez moi : 32 MB/sec).

    3. Tu parles de copies (c'est à dire lecture+écriture). Je suppose qu'il s'agit de copies "mono-disque". Je fais fais souvent des copies mais jamais en mono-disque : c'est bien trop lent. J'ai déjà pu constater que des copies de disque à disque (chez moi sur deux controlleurs ide différent) vont (parfois) 8x plus vite que des copies mono-disque (et ça fait nettement moins de bruit).

    4. Tu dis que tu "flirtes" avec moins d'1MB de libre : au prix du GB actuel, on
    peut appeler cela de la gourmandise (tu aimes le risque ... un peu trop sans
    doute).

    5. Oui, il y a de la fragmentation sous Linux (quelques % chez tout le monde, sauf chez toi). Non, on ne passe pas son temps à défragmenter son FS (on le
    calibre à ses besoins).

    6. Achète-toi un disque externe usb (ou comme moi, récupère un disque IDE
    qu'on peut placer dans un container usb) : ça coûte pas cher et ça évite des
    trolleries.

    J'attends avec impatience ton comparatif sur "quelques" distributions Linux
    et Windows XP (et aussi Vista ?) : ça va troller sec !

    PS: prends un peu de recul et n'oublie pas aussi les macs, les freebsd, ...

Suivre le flux des commentaires

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