ShaKe, un défragmenteur pour GNU/Linux

Posté par (page perso) . Modéré par Florent Zara.
Tags :
0
20
août
2006
Linux
ShaKe est un logiciel libre qui met à disposition de tous les (GNU/)Linuxiens le plaisir de la défragmentation. En effet, et contrairement à xfs_fsr, il n'utilise que les fonctions du noyau communes à la plupart des systèmes de fichiers. Plus qu'un portage, il essaie également d'apporter une touche d'originalité, par exemple avec l'idée d'une défragmentation sélective.

Deux notes cependant :
  • Son utilisation requiert d'avoir monté la partition avec le support des attributs étendus ("user_xattr").
  • Ce n'est pas un outil d'usage hebdomadaire, plutôt quelque chose à utiliser tous les un ou deux ans pour le principe (sauf si l'on a trop de fichiers sparses). Ceci dit, les utilisateurs actuels disent avoir ressenti un réel bénéfice, et n'ont généralement pas eu de problèmes.
Concrètement, cette sélectivité prend la forme d'un jeu de critères visant à estimer le coût réel de la fragmentation, pour évaluer si la défragmentation est rentable.
En premier lieu, il cherche les "amis" du fichier. Par défaut ce sont les fichiers du même dossier ayant un atime proche.
Ensuite il exprime des exigences, notamment le nombre maximal de fragments, le nombre maximal de "miettes" (minuscules fragments qui font faire des déplacements consécutifs à la tête de lecture), et la distance vis à vis des amis (utile pour des programmes comme dpkg, make ou portage qui manipulent de nombreux fichiers d'un même dossier).
Ces exigences sont exprimées sous formes de seuils que les statistiques du fichier ne doivent pas dépasser.
Après cela, il examine la taille des fichiers et les classe en trois catégories : ceux qui sont petits et qui correspondent surtout à une fragmentation de l'espace libre (typiquement un fichier de configuration), ceux qui sont énormes (typiquement un film), et les autres.
À chacune de ces catégories il associe une tolérance, qui multiplie les seuils.
Enfin, il prends sa décision.

Il a également d'autres stratégies, par exemple éviter que des fichiers restent trop longtemps au même endroit en ré-allouant l'espace des vieux fichiers.
Il propose aussi un mode "lecture seule" (--pretend) dans lequel il ne fait qu'afficher des statistiques. Utilisé conjointement avec le module python pré-alpha qui extrait les informations de la sortie standard, il permettras à terme de faire une interface graphique plus classique, ou des statistiques détaillés sur la fragmentation.

Pour conclure, voici quelques exemples, extraits de la manpage :
Voir la fragmentation d'un dossier : shake --pretend --verbose --verbose DOSSIER
Examiner tous les MP3 des sous-dossiers, en conseillant de placer à coté ceux qui sont proches dans l'ordre lexical : find -type f -iname '*.mp3' | sort | shake
  • # Re: Pourquoi Linux n'a pas besoin de défragmentation

    Posté par (page perso) . Évalué à 10.

    Apparement les modérateurs ont ajouté à ma proposition initiale de dépêche un lien qui présente pourquoi Linux n'a pas besoin de défragmentation.

    De mon point de vue, cet article est dans le vrai : dans la quasi-totalité des cas le système de fichier sait se débrouiller tout seul.
    ShaKe vise précisement à déceler les seuls cas où le système de fichier échoue.

    Il y en a au moins trois :
    Premièrement, le cas où le disque est trop plein. Lors de la présentation à mes profs (à la base c'est un projet d'étude à Lyon1), j'avais fourni une image de filesystem qui faisait bien ressortir le problème : http://vleu.net/shake/disk.bin.bz2 . Sur cet exemple (très articiel), les fichiers "gros" (un méga si je me rappelle bien) passaient d'un millier de fragments à quelques uns. Le cas de cet utilisateur montre que ça arrive aussi dans la vraie vie http://forums.gentoo.org/viewtopic-t-463204-postdays-0-posto(...) .
    Ensuite, les "fichiers sparses". Quand un programe Linux accède par exemple au 60ème méga octet d'un d'un fichier qui n'en fait que 5, le système de fichier ne génére pas un fichier plein de zeros pour "remplir le trou" mais "saute par dessus". On a alors systèmatiquement deux fragments. C'est une fonctionalité très interessante puisqu'elle fait gagner une quantitée non négligeable d'espace disque. Mais les logiciels de peer to peer (notament) lui causent problèmes car il reçoivent les morceaux dans un ordre plus ou moins aléatoire, ce qui cause de nombreux sauts et une fragmentation importante. Shake détecte ces sauts injustifiés, mais aussi ajoute des sauts dans le cas où il seraient utiles.
    Enfin, il y a le problème de l'évolution de la taille et de l'usage des fichiers. ReiserFS (extN aussi je suppose) semble s'arranger pour placer les fichiers d'un même dossier ensemble, et dans l'ordre d'écriture. Mais aussi intelligent soit-il, le système ne peut pas anticiper deux ans d'utilisation, et si par exemple un dossier se voit ajouter une centaine de fichiers après être longtemps resté intact, ou si un fichier grossit sans cesse longtemps encore après avoir été crée, il seras bien obligé de fragmenter.

    Il y a aussi d'autres choses, comme le fait que l'ordre d'écriture ne soit pas nécessairement l'ordre de lecture (shake réecrit les fichiers éloignés les un des autres dans l'ordre de lecture) et le fait que de nombreux fichiers restent "sur place" longtemps, fragmentant l'espace libre car le FS ne va pas de lui même les déplacer (shake les réecrit aussi).

    Pour résumer : il y a des cas (rares) où les hypothèses que le système de fichier avait fait sur l'utilisateur, ou sur l'usage des fichiers sont fausses. Shake notifie le problème au système de fichier simplement en lui intimant l'ordre de les réecrire. L'efficacité du système de fichier sous jacent est donc justement ce qui fait marcher Shake et cet article va dans mon sens.
    Par contre, s'il est donc suceptible d'être utile, ce n'est bel et bien pas au quotidien car ces cas sont rares.
  • # Réponse au 3° lien

    Posté par (page perso) . Évalué à 2.

    L'un des développeurs de KDE a fait une réponse à l'article cité en 3° lien qu'il a intitulé :
    Why does Linux need defragmenting?
    http://www.kdedevelopers.org/node/2270

    En "rangeant" les fichiers, Shake semble répondre à sa problématique.
    Tu devrais lui proposer ;)
    • [^] # Re: Réponse au 3° lien

      Posté par . Évalué à 7.

      Au contraire de l'analyse effectuée ici, je ne pense pas que celle du dev kde soit très pertinente. Pourquoi?
      il compare le démarrage de kde depuis le disque au démarrage de kde depuis le cache!
      Il a juste découvert que quand des données étaient en cache, on y accédait plus vite. C'est tout.

      Après c'est vrai que c'est dû au seeks, mais aucun rapport avec la fragmentation puisque précisément, comme *il* l'explique, ce sont des seeks entre fichiers, pas entre fragments du même fichier.

      Et le fait de positionner les fichiers lu l'un après l'autre pour accélérer la chose ne fonctionne que si le noyau gère ça (réordonnancement des opérations par le hardware plus souvent que par le noyau, parce qu'il se connait mieux que le noyau), et c'est encore en developpement.
      • [^] # Re: Réponse au 3° lien

        Posté par (page perso) . Évalué à 3.

        Relis encore.

        Il précise que, considérant une vitesse de lecture des disques dur de 50Mo/s , et que le lancement de KDE ne devrais pas charger plus de 100Mo (mon cache ne fait même pas autant), il devrais y avoir une différence de 2 secondes entre démarrer avec ou sans cache.

        Or, j'ai fait le test, j'observe une différence de 20 secondes, soit 10 fois plus.
        C'est donc bien car les fichiers sont a des endroit différent du disque.

        Maintenant, ShaKe va remettre les fichier des même dossiers à des endroit proche. Ça semble être la solution puisque bcp des fichiers lu au démarrage sont dans les même dossiers.

        Ça me rappelle cette news sur "Accelerated Knoppix"
        http://linuxfr.org/2006/03/03/20432.html
        • [^] # Re: Réponse au 3° lien

          Posté par . Évalué à 4.

          Il précise que, considérant une vitesse de lecture des disques dur de 50Mo/s , et que le lancement de KDE ne devrais pas charger plus de 100Mo (mon cache ne fait même pas autant), il devrais y avoir une différence de 2 secondes entre démarrer avec ou sans cache.

          C'est un raisonnement sur un modèle idéal, mais en pratique d'autres facteurs vont dégrader les performances :
          - la mise à jour de métadonnées (la date du dernier accès si tu n'as pas activé le drapeau noatime)
          - d'autres événements peuvent avoir lieu en même temps (par exemple des ajouts dans un fichier log)
          - pour atteindre ces vitesses maximales, le noyau doit être capable de mettre constamment en file d'attente les requêtes, par exemple en calculant du prefetching, ce qui n'est pas évident si les données à charger sont éparpillées sur une myriade de petits fichiers (comme le noyau peut-il prévoir qu'après /usr/lib/libkoko.so.2, c'est /usr/lib/libkarcher.so.4 qui doit être mise en file d'attente ?)

          Sans compter qu'optimiser le temps de lancement de KDE ne sera pas forcément bénéfique pour d'autres cas d'usages (lancement de telle ou telle application) qui interviendront peut-être plus souvent en utilisation intensive.
          • [^] # Re: Réponse au 3° lien

            Posté par (page perso) . Évalué à 1.

            pour atteindre ces vitesses maximales, le noyau doit être capable de mettre constamment en file d'attente les requêtes, par exemple en calculant du prefetching, ce qui n'est pas évident si les données à charger sont éparpillées sur une myriade de petits fichiers (comme le noyau peut-il prévoir qu'après /usr/lib/libkoko.so.2, c'est /usr/lib/libkarcher.so.4 qui doit être mise en file d'attente ?)
            C'est justement ce qui est dit. Et justement, a priori, Shake devrait pouvoir réduire ce temps que l'on doit au morcellement en rapprochant les fichiers à charger.
            • [^] # Re: Réponse au 3° lien

              Posté par . Évalué à 3.

              Mais non, ce n'est pas parce que deux fichiers sont contigus que le noyau va se mettre à préfetcher le deuxième après avoir lu le premier (enfin, je ne pense pas).
              Il y aura donc un intervalle de temps pendant lequel le disque dur ne fera rien et le débit maximal ne sera pas atteint.
              • [^] # Re: Réponse au 3° lien

                Posté par . Évalué à 2.

                Tout dépend de la logique interne au disque. Si elle décide de cacher tout ce qu'il y a autour de la dernière lecture, ça peut effectivement aider.
            • [^] # Re: Réponse au 3° lien

              Posté par . Évalué à 4.

              Non, à la limite, il faudrait FRAGMENTER les lib pour que ça aille plus vite au démarrage.

              Les libs, pour la plupart lors du lancement d'applications, ne sont pas ouverts et lus, mais elles sont mappées, donc l'accès sur le fichier est pseudo aléatoire ...

              Il vaut mieux optimiser le placement des symboles et le layout des lib plutôt que de trafiquer le système de fichier AMHA.
          • [^] # Re: Réponse au 3° lien

            Posté par . Évalué à 1.

            Il faut noter aussi le rôle que peut jouer l'ordonnanceur gérant les entrées/sorties sur le disque dur.

            Le comportement et les performances peuvent sensiblement varier en fonction de l'ordonnanceur utilisé (Noop, AS, Deadline ou CFQ voire ceux à base d'algos génétiques) et le type d'utilisation associé.

            THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.

        • [^] # Re: Réponse au 3° lien

          Posté par . Évalué à 3.

          >il devrais y avoir une différence de 2 secondes entre démarrer avec ou sans cache.
          Ce n'est pas le bon calcul, celui-ci se base sur le débit en séquentiel, alors qu'il faut le faire plutôt sur le temps d'accès. Quand est-ce que le débit pur d'un disque est utile? Quand tu fais une lecture d'un gros fichier, pas quand tu lis des fichiers de config.

          Dans le cas de KDE, même si les fichiers sont physiquement proches, il ne va pas les lire à la suite les uns des autres. Lles autres tâches vont ajouter leurs propres accès à la file des opérations disques (réessaie le lancemen de kde, cette fois après avoir lancé une copie-pas deplacement, hein, copie- d'un fichier d'un Go entre deux emplacements sur un même disque dur). Peut ere même qu'elle en profitera pour écraser le cache disque par la même occasion...
          • [^] # Re: Réponse au 3° lien

            Posté par . Évalué à 6.

            Ah et comme l'a montré un dev noyau, si les desktops ne passer pas leur temps à stat'er plusieurs fois les même fichier et ne chargeait pas la totalité des polices au démarrage, ça irait un peu plus vite :D
    • [^] # Re: Réponse au 3° lien

      Posté par . Évalué à 1.

      Pourquoi shake ou un systeme équivalent n'est il pas integré au systeme de fichier qui mesurerait l'usage et l'ordre d'usage des différents fichiers et pourrait mettre à la suite les fichiers qui sont souvent utilisés ensemble. Un peu comme un compilateur qui fait de l'optimisation globale.

      Il pourrait aussi éviter la fragmentation pour les fichiers qui sont le plus utilisés (la fragmentation d'un fichier "mort" n'est pas importante). Tout cela, pourrait se faire de temps en temps automatiquement quand le cpu/disk ne fait rien.
      • [^] # Re: Réponse au 3° lien

        Posté par . Évalué à 2.

        Probablement parce que plein d'adolescents boutonneux n'y connaissant rien et n'ayant jamais programme de leur vie se mettraient a critiquer le fait qu'il y a un defragmenteur, que c'est inutile sous Linux car c'est bien connu sous Linux les FS ne fragmentent jamais et qu'il faut pas faire comme Windows parce que c'est Mal(TM).

        Moi ironique ? Naaaaan....
  • # Exercice de style ?

    Posté par (page perso) . Évalué à -1.

    On peut se demander si ce programme est vraiment utile vu que tous les FS créés pour les Unix (Linux inclus) ont traité le problème à la base au lieu de faire du curatif. C'est exactement comme pour les virus, en prenant toutes les précautions leur existence devient quasi-impossible.

    Je pense donc que si l'utilité de ce programme est marginale, il s'agit néanmoins d'un bel exercice de style.

    Il existe un défragmenteur humoristique que nous devons à Sébastien Blondeel :
    --------------------------------------------------------------------------------------------
    #!/bin/sh
    echo "Defragmenting all hard drives"
    for pourcent in `yes | head -100 | cat -n | sed 's/y//'`
    do
    echo "... $pourcent% completed"
    sleep 5
    done
    echo "Now your system is nice and clean and ready to run faster!"

    -- sbi (défragmenteur pour système de fichier ext2)
    --------------------------------------------------------------------------------------------
    et une variante issue d'une compétition spontanée sur la liste tech de l'ABUL :
    --------------------------------------------------------------------------------------------
    #!/bin/bash
    for i in `seq 100`
    do
    echo $i
    sleep 1
    done | dialog --backtitle "Défragmenteur de disque universel (ext2/ext3, ReiserFS, XFS et JFS)" --title "defrag" --gauge "Défragmentation en cours ..." 18 60

    dialog --backtitle "Défragmenteur de disque universel (ext2/ext3, ReiserFS et Vfat)" --title "defrag" --msgbox "Défragmentation terminée avec succès" 18 60

    exit
    --------------------------------------------------------------------------------------------
    • [^] # Re: Exercice de style ?

      Posté par . Évalué à 7.

      On peut se demander si ce programme est vraiment utile vu que tous les FS créés pour les Unix (Linux inclus) ont traité le problème à la base au lieu de faire du curatif. C'est exactement comme pour les virus, en prenant toutes les précautions leur existence devient quasi-impossible.

      Cela n'a rien à avoir avec les virus. L'existence des virus se base sur l'existence de failles (conceptuelles ou d'implémentation) dans le modèle de sécurité. Ces failles sont observables de façon objective au moment de leur introduction.
      Ici il ne s'agit pas de colmater des failles, de pallier au fait qu'il est impossible de prévoir l'avenir, et donc de savoir à l'avance quelle doit être l'organisation optimale du disque dur.

      On sait bien que les systèmes de fichiers utilisés avec Linux font un boulot relativement correct pour éviter au maximum la fragmentation, mais on ne peut prétendre que la défragmentation est rigoureusement inutile.

      Il serait intéressant, par exemple, de savoir l'impact que peut avoir l'utilitaire ici présenté sur les performances d'une base MySQL fréquemment modifiée (notamment avec des champs à taille variable type BLOB).
    • [^] # Re: Exercice de style ?

      Posté par . Évalué à 4.

      Je me demande si tu as lu le journal et le premier commentaire...
    • [^] # Re: Exercice de style ?

      Posté par . Évalué à 6.

      Je vous invite à lire ce blog qui montre très clairement la différence de vitesse qui existe entre un FS tout neuf et un utilisé depuis quelques mois :
      http://www.sabi.co.uk/Notes/anno05-4th.html#051226b

      Dans d'autres articles du blog, il constate aussi que les performances se dégradent plus vite en ext3 qu'avec d'autres systèmes de fichier.
  • # ^-^

    Posté par . Évalué à 2.

    J'ai une partition qui est fragmentée à plus de 28%, et qui rame d'une force... (Vive aMule, et les logiciels de P2P en général, qui alloue l'espace disque dynamiquement).

    Pour moi, la fragmentation sous Linux existe, et n'est certainement pas négligeable. La différence de performances sur les disques durs est la première chose qui m'a frappé lorsque j'ai switché de Windows, il y a quelques années. Même avec son écriture différée et autres artifices (qui au passage m'a emmerdé je ne sais combien de fois lors d'une écriture sur clé USB), la gestion des disques sous Linux est moins performante que sous Windows.

    Par exemple, copier un gros fichier (genre une iso) est non seulement plus lent sous Linux, mais en plus ça me fait tout ramer (le curseur de la souris saccade, les autres applications mettent 3 plombes à réagir, et ne parlons pas d'ouvrir un programme à ce moment là !), et j'ai pu vérifier cela avec différentes distributions (Mandriva, Debian, Ubuntu, etc.).

    Le problème est bien présent, et les personnes qui l'éludent en prétextant qu'il n'existe pas n'ont soit pas utilisé Windows depuis des années, soit font preuve d'une certaine dose de mauvaise foi.

    Cela dit, je ne suis pas certain que la fragmentation soit la raison du problème de différence de performances dans la gestion des disques. Certes, cela doit jouer un peu, mais à mon avis, le noyau est le principal responsable.
    • [^] # Re: ^-^

      Posté par . Évalué à 4.

      Tu as activé la DMA ?
      • [^] # Re: ^-^

        Posté par . Évalué à 8.

        Non non, j'aime bien quand ça rame.
    • [^] # Re: ^-^

      Posté par . Évalué à 5.

      Par exemple, copier un gros fichier (genre une iso) est non seulement plus lent sous Linux, mais en plus ça me fait tout ramer (le curseur de la souris saccade, les autres applications mettent 3 plombes à réagir, et ne parlons pas d'ouvrir un programme à ce moment là !), et j'ai pu vérifier cela avec différentes distributions (Mandriva, Debian, Ubuntu, etc.).
      Ça c'est fréquent quand le DMA n'est pas activé. T'as quoi comme chipset ?
      Pour ma part, j'ai jamais vu de tels problèmes sur mes machines, par contre je l'ai déjà vu sur la machine de quelqu'un d'autre où la carte mère était en train de mourir... (et sous windows ça merdait tout autant)
      • [^] # Re: ^-^

        Posté par . Évalué à 4.

        Bon, trève de plaisanteries : le DMA est bien évidemment activé. :p
        La carte mère est une Asus A7N8X, chipset NForce2, et à l'époque où j'avais encore Windows en dual boot, aucun problème sous Windows.

        $ dmesg|grep DMA
        NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
        ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
        ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
        hda: 241254720 sectors (123522 MB) w/1821KiB Cache, CHS=16383/255/63, UDMA(100)
        hdb: 241254720 sectors (123522 MB) w/1863KiB Cache, CHS=65535/16/63, UDMA(100)
        hdc: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(133)
        hdd: ATAPI 63X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(33)
        parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
        • [^] # Re: ^-^

          Posté par (page perso) . Évalué à 3.

          "hdparm -tT /dev/hda" donne pour mon portable sous mandriva 2007 beta

          /dev/hda:
          Timing cached reads: 1072 MB in 2.01 seconds = 534.23 MB/sec
          Timing buffered disk reads: 70 MB in 3.16 seconds = 22.14 MB/sec


          et "hdparm /dev/hda"
          /dev/hda:
          multcount = 16 (on)
          IO_support = 0 (default 16-bit)
          unmaskirq = 0 (off)
          using_dma = 1 (on)
          keepsettings = 0 (off)
          readonly = 0 (off)
          readahead = 256 (on)
          geometry = 16383/255/63, sectors = 78140160, start = 0

          et toi ?

          NB : les débits ne sont pas fantastiques car la puce gérant l'ide est juste une ide66
          • [^] # Re: ^-^

            Posté par . Évalué à 2.

            # hdparm -tT /dev/hda
            /dev/hda:
            Timing cached reads: 1204 MB in 2.00 seconds = 601.08 MB/sec
            Timing buffered disk reads: 112 MB in 3.06 seconds = 36.65 MB/sec

            # hdparm /dev/hda
            /dev/hda:
            multcount = 0 (off)
            IO_support = 1 (32-bit)
            unmaskirq = 1 (on)
            using_dma = 1 (on)
            keepsettings = 0 (off)
            readonly = 0 (off)
            readahead = 256 (on)
            geometry = 16383/255/63, sectors = 241254720, start = 0

            # hdparm -tT /dev/hdb
            /dev/hdb:
            Timing cached reads: 1332 MB in 2.00 seconds = 666.14 MB/sec
            Timing buffered disk reads: 134 MB in 3.02 seconds = 44.40 MB/sec

            # hdparm /dev/hdb
            /dev/hdb:
            multcount = 0 (off)
            IO_support = 1 (32-bit)
            unmaskirq = 1 (on)
            using_dma = 1 (on)
            keepsettings = 0 (off)
            readonly = 0 (off)
            readahead = 256 (on)
            geometry = 65535/16/63, sectors = 241254720, start = 0

            bon, hdc est sensiblement dans les mêmes eaux. (Évidemment le problème, c'est hda, qui carbure à du 5 Mo/s en transfert de gros fichiers au mieux, alors que hdb et hdc tournent à 20~30 Mo/s)
            • [^] # Re: ^-^

              Posté par (page perso) . Évalué à 2.

              bon, hdc est sensiblement dans les mêmes eaux. (Évidemment le problème, c'est hda, qui carbure à du 5 Mo/s en transfert de gros fichiers au mieux, alors que hdb et hdc tournent à 20~30 Mo/s)
              C'est peut être effectivement un cas de fragmentation. Dans ce cas tu pourrais faire un bon client pour shake.
              Si t'a le temps, essaie donc shake --no-xattr --new=0 /. Si ça marche mal (y'a du tweaking à faire sur certaines constantes...), essaie de m'envoyer le shake -pvv d'un gros fichier.
              Et vérifie que t'a pas une partition ReiserFS3 montée sans notail, c'est le piège.
              Du reste, je suis de bonne foi et les ralentissements dont tu parle ne m'affectent pas. Essaie d'autres système des fichiers et ordonanceurs (j'ai Reiser3 sans notail et avec atime, l'anticipatory scheduler). Le problème ne peut venir que de là.
            • [^] # Re: ^-^

              Posté par . Évalué à 2.

              L'option multcount est sur off, ça joue peut-être sur les performances. C'est l'option -m de hdparm. Essaie avec -m16 ou -m32 par exemple.
            • [^] # Re: ^-^

              Posté par . Évalué à 4.

              Ça dépend aussi avec quoi tu copies : j'avoues que j'ai le réflexe terminal, et que je n'utilise pas souvent nautilus, mais cette bouse fait ramer mon ordi comme c'est pas permis lors d'une simple copie de fichier (et je parle même pas d'une copie depuis un share samba ...) : CPU quasi à 50%, etc ... alors qu'avec un bon vieux cp, pas de problème.

              Je te conseille un petit oprofile quand ton système rame, pour savoir d'où ça vient :

              oprofile --init
              oprofile --setup --vmlinux=/boot/vmlinux
              oprofile --reset
              oprofile --start
              [lancer la copie, attendre un peu ...]
              oprofile --stop

              Puis un petit opreport -l après, et regarde ce qui vient en haut. Enlève le '-l' pour avoir le classement par appli. Chez moi il passait plein de temps à faire du malloc() et d'autres joyeusetés (à quoi ça sert d'utiliser un buffer constant pour la copie, alors qu'on peut s'amuser à le redimensionner à chaque fois \o/ ...)
        • [^] # Re: ^-^

          Posté par . Évalué à 2.

          Je précise que j'ai Linux sur 2 ordinateurs totalement différents (un à base d'AMD, l'autre à base d'Intel, avec disques durs de marques différentes, avec distributions différentes, etc.), et que le problème est le même sur les 2 machines.
          • [^] # Re: ^-^

            Posté par . Évalué à 2.

            Je ne constate pas ce genre de problème (Debian testing sur A7N8X mais avec 3 disques en SCSI et sur un portable Dell lui en IDE).
            La seule fois ou j'ai eu ce genre de problème c'était avec une knoppix où le dma n'était pas activé.
          • [^] # Re: ^-^

            Posté par . Évalué à 3.

            Ben t'as deux machines de merde :P
            • [^] # Re: ^-^

              Posté par . Évalué à 2.

              Ouais, mais là tu ne m'apprends rien ! :-)
    • [^] # Re: ^-^

      Posté par . Évalué à 8.

      Tiens, c'est marrant, c'est entre autres le constat exactement inverse qui m'a fait switcher sous linux il y'a près de 10 ans... (sans parler du fait qu'un accès disquette ou CD ne bloquait pas la machine, par exemple...)
      • [^] # Re: ^-^

        Posté par . Évalué à 5.

        Idem pour moi,

        je trouve justement que sous Linux, les transferts de gros dossiers (plusieurs gigas) font moins ralentir le système que sous Windows (sans parler du fait que les fenêtres de transfert peuvent etre réduite sous linux, et pas sous windows...).

        Par ailleurs, même lancer des transferts depuis des zones différentes du disque vers 2 localités différentes (un autre disque interne et un disque externe) est également "mieux" réalisé sous linux, le reste du système répondant toujours assez bien (alors que sous windows, ça rame vraiment à fond).

        Je suis sous Kubuntu Dapper avec des partitions XFS (précedemment Mandriva, ReiserFS).
        • [^] # Re: ^-^

          Posté par (page perso) . Évalué à 4.

          Personellement, un transfert de gros fichier rame autant chez moi sous Linux que sous Windows...
          Les autres applicatiosn ne deviennent pas inutilisables mais dans une lecture de video par exemple, il y a un lag certain.
          • [^] # Re: ^-^

            Posté par . Évalué à 3.

            Perso aussi bien sur mes machines laptop que sur desktop les transferts de fichiers quelques soient leur origines et destination n'ont jamais fait ramer une lecture vidéo. J'imagine que le prefetching de la lecture séquentielle d'un fichier fait bien son travail ici, elle a du se mettre en greve ailleurs :p.
            Par contre ça me ralenti enormement le lancement des programmes, ce qui est normal (enfin en théorie ça pourrait etre évité si le système pouvait distinguer entre un acces ponctuel avec necessité d'un temps de réponse bas, tel un chargement de programme / biblio, et un bulk transfert qui ne perd rien à être interrompu n'importe quand de manière temporaire).
            • [^] # Re: ^-^

              Posté par (page perso) . Évalué à 2.

              Ici j'ai du chiffrement de fichier sur tout mes disques (sauf / et /home pour pas être ennuyé) aes2048...

              Et bien ça marche rudement bien, même les vidéos sauvées sur une partition chiffrée se lisent sans lag...

              Seul bémol, l'écriture de gros fichier (copie/écriture) mette a genoux le processeur...

              Et un téléchargement p2p type bittorrent avec 22iso a 256ko/s me bouffent environ 40-50% système et pratiquement autant en utilisateur...
              (athlon 3200+ 512k)

              Plus sérieusement les copies de (gros) fichiers on toujours tendance a mettre a genoux le processeur...

              Mais sur de l'ide les performances sont maximisées quand les disques sont seul sur un contrôleur ide...
              (même avec des cartes extensions ide bas de gamme on gagne en performance...)

              Après certaines architectures sont meilleures que d'autre, les nforce en dual channel donne de meilleur résultat chez moi au niveau réactivité
              (enfin c'est une forte impression)
        • [^] # Re: ^-^

          Posté par . Évalué à 4.

          Personellement avec deux pc à la maison un sous windows et un sous ubuntu, kubuntu, suse, mandriva et bientot freespire (les partitions et grub ca sert chez moi ;-p ) je constate que lorsque je déplace de gros fichiers avec windows l'ordi est à genoux alors que sous linux meme si j'ai des lags en lecture video et audio, je peu surfer sur internet tchater ouvrir d'autres fenêtres le temps de réponse n'est pas le même mais au moins ma machine répond.


          <\hs Sinon Nikoo XFS t'apporte quoi de plus par rapport a reiser4 ou ext3 \hs>
          • [^] # Re: ^-^

            Posté par . Évalué à 1.

            <\hs

            Ben, je ne sais pas trop en fait :p.
            Il me semble avoir lu quelque part que XFS était plus rapide, et comme j'avais décidé de passer de Mandriva à Kubuntu, j'ai en même temps décidé de reformater mes partitions dans ce format pour essayer.

            Donc avec la même charge de disques, mon système m'a l'air plus rapide et semble mieux répondre.

            Mais, et c'est un gros mais, comme je suis en même temps passé à Kubuntu, j'ignore si finalement ce n'est pas la distribution qui possède ces plus.

            Donc en gros, je ne sais pas ce que ce passage XFS>ReiserFS m'a apporté.

            :p

            P.S. on se moque pas, merci ;-)

            \hs>
            • [^] # Re: ^-^

              Posté par . Évalué à 3.

              J'espère que ta machine est stable et branchée sur un onduleur, XFS fait un usage énorme du cache, ce qui engendre pas mal de pertes lors d'un problème.
              Perso, j'avais essayé, je suis revenu à ext3 : marre de perdre des dizaines de fichiers modifiés à chaque plantage, mon PC n'étant pas un modèle de stabilité
        • [^] # Re: ^-^

          Posté par . Évalué à 2.

          (léger HS) j'avais eu une mauvaise expérience lors d'une copie de gros fichiers d'une mauvaise grosse clé USB: après coup, je m'apercevais que les md5sum des fichiers sur ma clé étaient variables (!). Après une nuit, je m'apercevais que la clé était morte :-(

          Donc, la fois d'après, j'ai fait avec un disque dur externe, et pour rapatrier vers mon ordi principal, échaudé par la dernière fois, je m'armais de mon md5sum.

          Dans un terminal, je fais cp --verbose *.iso /dest/
          dans l'autre, je fais md5sum *.iso

          Et alors ?

          Alors, c'est trop fort: le md5sum m'affiche le checksum d'un fichier au moment même au cp --verbose m'annonce qu'il attaque la copie du suivant.

          Les caches font quand même des merveilles: je fais deux traitement sur mes données pour le prix d'un accès disque. C'était ma petite soirée contemplative

          Al.
      • [^] # Re: ^-^

        Posté par . Évalué à 6.

        J'ai fait le même constat, principalement sur des petits fichiers. Lorsque je copie 100Mo de petits fichiers sur ma clé USB (2.0) depuis Windows (au boulot) Windows rame comme un con et commence par me dire qu'il se "prépare à déplacer" les fichiers. Ensuite j'ai droit à une joli barre de progression qui m'annonce... 25 min restantes. J'ai le temps d'aller pisser, de prendre un café, de blablater à la machine à café et quand je reviens ça n'est pas encore fini. Sous linux il y en a pour 2 minutes à tout casser. Si au contraire je copie un gros fichier, le temps est aproximativement le même des deux côtés.
        • [^] # Re: ^-^

          Posté par . Évalué à 4.

          perso, quand j'ai de petit fichiers a deplacer sur cle usb je les zippe, si non c'est ingerable.....
          • [^] # Re: ^-^

            Posté par (page perso) . Évalué à 2.

            Et le pauvre linuxien condamné à utiliser Windows découvrit SuperCopier, et son existence en fut bouleversée. Un outil de copie qui remplace celui d'Explorer, qui est rapide, ne plante pas (ou au moins, moins que celui d'Explorer :p) et est réductible en zone de notification.
            • [^] # Re: ^-^

              Posté par . Évalué à 1.

              D'ailleurs si quelqu'un connaît un équivalent pour KDE je suis preneur. Plus spécifiquement la possibilité de pouvoir rajouter une copie dans une file d'attente. C'est quand même plus rapide que de faire trois copies en même temps à trois endroits différents du disque dur.
              • [^] # Re: ^-^

                Posté par (page perso) . Évalué à 2.

                Si Kget gère tes déplacement ça devrais être bon. Après peut être qu'il ne marche que pour le http, mais y'a pas de raisons.
        • [^] # Re: ^-^

          Posté par . Évalué à 2.

          N'oublions pas que windows est équipé de cette merveille nommée «explorateur».
          C'est la plupart du temps lui qui s'accapare toutes les ressources.

          Si vous avez le temps (rare) et des utilisateurs capables de faire planter excell en réseau (très courant), essayez d'effacer en utilisant l'explorateur les fichiers dump générés par cet excellent tableur si professionnel. Bon courage !!!
          Un simple clic droit sur le fichier (qui peut faire 5-6Go) le charge en mémoire. À moins de posséder 10Go de mémoire sur le serveur win2003, bin y en a pour la matinée avant d'avoir le menu contextuel.
    • [^] # Re: ^-^

      Posté par (page perso) . Évalué à 5.

      Même avec son écriture différée et autres artifices (qui au passage m'a emmerdé je ne sais combien de fois lors d'une écriture sur clé USB)

      Même problème sous Windows, qui a aussi des systèmes de cache: il faut s'assurer que le cache est bien vidé avant de déconnecter la clée.

      Sous Windows il y a "retirer le périphérique en toute tranquilité/sécurité"

      Sous KDE, il y a qq chose d'équivalent (et ça doit sûrement se trouver sous Gnome) qui permet de démonter un volume amovible avant de le déconnecter.

      Parce que - expérience personnelle - ça m'est arrivé de faire sous Windows une copie de nombreux fichiers d'un HD vers une clé USB, d'attendre que la fenêtre de copie soit refermée, puis de retirer la clé immédiatement. Hé ben j'ai foiré -et bien foiré- la table d'allocation FAT de la clé.
      Depuis je passe systématiquement par les outils de démontage "en toute sécurité".

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

      • [^] # Re: ^-^

        Posté par . Évalué à 2.

        sous windows cet usage est meme RECOMMANDE par les techs de microsofts eux-meme.

        et si la fonction existe ce n'est surement pas pour rien.

        je confirme que sous gnome il y a aussi un menu pour "demonter"/"ejecter" le peripherique amovible avant de le debrancher.
        • [^] # Re: ^-^

          Posté par . Évalué à 2.

          Cette fonction, elle ferait bien d'exister pour les disquettes aussi, comme sous Linux.

          Des collègues, qui regardaient la fenêtre au lieu de la diode du lecteur ont niqué des boites entières de disquettes comme ça !!!
          • [^] # Re: ^-^

            Posté par (page perso) . Évalué à 2.

            pour les disquettes

            Des disquettes, des disquettes... ah oui, ces petits bouts de plastiques plats et fragiles avec un disque souple à l'intérieur :-)

            J'en ai encore un lecteur sur ma machine au boulot... mais chez moi ils sont démontés (finalement je passe par une clé USB, même Linux sait la gérer). Le seul moment où j'en aurais vraiment besoin... c'est pour flasher le BIOS de la carte mère - ça semble le seul moyen supporté par certains fabriquants: du (free)DOS + une appli à eux qui tappe directement dans le matériel.

            Et c'est toute une galère pour trouver un support...

            Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # en cours d'utilisation

    Posté par . Évalué à 2.

    interressant comme projet,
    il est ecrit sur le site que le FS peu être defragmenter en cours d'utilisation.
    que ce passe t'il si shake defrag un gros fichier et qu'une application souhaite y acceder en lecture ? en ecriture?.. par exemple les données d'une base de données ?...
    • [^] # Re: en cours d'utilisation

      Posté par (page perso) . Évalué à 5.

      Après avoir obtenu le descripteur de fichier, la première chose que ShaKe fait est de tenter de prendre un verrou dessus (dans investigate (char *name, struct law *l), ligne 93 de judge.c :
      /* Put the lock */
      if (l->locks && -1 == flock (a->fd, LOCK_EX | LOCK_NB))
        {
         error (0, errno, "%s: failed to acquire a lock", a->name);
         goto freeall;
        }
      ).
      Le problème ne peut donc se poser qu'avec les applications qui n'honorent pas les verrous. Le seul moyen de s'en prémunir serait d'activer le "Mandatory Lock", qui force les applications à respecter le verrous (documenté dans /usr/src/linux/Documentation/mandatory.txt ), mais de mon point de vue c'est un hack et je ne l'activerais que si c'est vraiment nécessaire.

      Il y a trois autres sécurité pour éviter les problèmes de corruption :
      La fonction capture (struct accused *a, struct law *l), à la ligne 177 de executive.c qui est appellée avant les opérations d'écriture masque les signaux (notement).
      Après une opération de défragmentation, il vérifie rapidement que rien ne manque.
      À tout moment, une copie du fichier en cours d'écriture est disponible. Si ShaKe échoue (par exemple à allouer la mémoire) il indique son emplacement puis se suicide.
      • [^] # Re: en cours d'utilisation

        Posté par . Évalué à 5.

        Le problème ne peut donc se poser qu'avec les applications qui n'honorent pas les verrous.

        Je crains que la majorité des applications ne prennent pas la peine de poser un verrou.
        Les seuls cas où un programmeur posera un verrou, ce sera quand il voudra interdire les accès concurrents depuis plusieurs instances de son appli, pas pour éviter qu'un utilitaire annexe dont il ne soupçonne pas l'existence (type défragmenteur) ne foute tout en l'air.
        • [^] # Re: en cours d'utilisation

          Posté par (page perso) . Évalué à 2.

          En fait, je devrais au moins permettre d'utiliser les mandatory locks.
          Je vais rapidement sortir une 0.25 pour me mettre en conformité avec Savannah, mais la 0.26 auras cette fonctionalité (probablement activée par défaut).
  • # Et sur du RAID

    Posté par (page perso) . Évalué à 3.

    Bonjour

    Y'a-t-il un intérêt de cet outil sur des partitions RAID (software), que ce soit 0,1 ou 5. Ou au contraire, cela risque de poser plus de problèmes qu'autre chose ?

Suivre le flux des commentaires

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