Journal gcp: un outil de copie à la cp

Posté par (page perso) .
Tags : aucun
35
28
sept.
2010
Bonjour à tous,

j'ai «profité» de la perte de ma boite de vitesse et de me retrouver coincé à Broome (Nord-Ouest de l'Australie... mais ne vous inquiétez pas, je profite aussi de la plage) pour avancer un petit projet que je voulais faire depuis longtemps.
gcp (Goffi's CoPier) est un outil de copie en ligne de commande à la cp, avec les quelques améliorations:

- une barre de progression (me souviens avoir vu un patch traîner à une époque sur gentoo pour en mettre une à cp, mais ce n'est pas en standard, c'est dommage)

- gcp continue la copie même en cas d'erreur: il saute juste le fichier en cause

- journalisation: les opérations sont écrites. Ainsi après la copie, vous pouvez savoir ce qui a été effectivement copié, ou si quelque chose a échoué. Typiquement, si vous essayez de copier un fichier root sans l'être, votre fichier sera copié (si les permissions vous l'autorisent), mais le changement de propriétaire ne sera pas possible: le journal affichera alors "PARTIAL: preserve-owner" ce qui signifie que la copie a fonctionné, mais pas le --preserve owner

- correction des noms de fichiers en cas d'incompatibilité avec le système de fichiers cible. Le cas typique, c'est la copie d'une fichier avec un "?", un "*" ou autre caractère interdit vers un disque en FAT. Avec cp ça ne marche pas, gcp corrige le nom pour que ça passe quand même... J'ai entendu «killer feature» dans la salle ?

- gcp ne gère qu'une queue de fichiers: si vous lancer une autre copie, gcp détectera l'autre instance et ajoutera ses fichiers à la première copie. Ainsi ça évitera à la tête de lecture de vos disques durs de faire des ballades tout le temps, et vous pouvez prévoir la fin de la copie plus facilement. Autre avantage: vous pouvez commencer une copie, pendant que vous cherchez d'autres fichiers à ajouter.

- possibilité de sauver la liste des fichiers sources. Le cas typique c'est si vous copiez toujours la même série d'albums de musique Libre pour faire découvrir à vos amis.

- gcp va garder une certaine compatibilité avec les options de cp. Attention cependant, le comportement sera toujours un peu différent (renommage des fichiers par exemple).

Voilà voilà, c'était pour mon besoin perso, mais mon petit doigt me dit que ça servira à d'autres. N'hésitez pas à m'envoyer des retours (notamment sur les performances par rapport à cp, je n'ai pas fait de test poussé, mais ça a l'air de se tenir).

Niveau améliorations, dans celles envisagées il y a:
- modification en temps réel de la queue de copie (pour mettre les fichiers à copier absolument en premier)
- une interface console avancée (probablement sous urwid)
- notifications après une copie un peu longue (via XMPP et peut être mail)
- relancer la copie des fichiers qui ont échoué (vous vous êtes pris les pieds dans le câble usb de votre disque dur)
- correction des nom unicode mal encodés
- vérification de la copie via un hash

dans celles envisageables il y a:
- une interface graphique
- une intégrations aux environnements de bureau (Kde, Gnome, XFCE, ...)
- copie des fichiers à distance (ftp/autre)
- une mode serveur basic pour la copie en réseau quand c'est trop reloud de monter un serveur nfs ou autre
- ... [votre idée ici]

Mais à noter que je ne pourrai pas bosser dessus avant au moins 2 mois.
Et je fini avec un petit lien vers mes autres projets en cours:
-lm (list movies): dont j'ai parlé ici: https://linuxfr.org/~Goffi/29966.html , et qui permet d'afficher vos films à la ls en utilisant les données de IMdB
-SàT (Salut à Toi): mon projet principal, un client XMPP multi-plateforme, multi-frontend, une base pour d'autres idées que j'ai en tête. J'en ai parlé ici: https://linuxfr.org/~Goffi/30073.html et je l'ai présenté ici: https://linuxfr.org/~Goffi/28287.html

et mon blog où vous pouvez suivre et télécharger tout ça: http://www.goffi.org
  • # Interessant

    Posté par . Évalué à 8.

    Ca m'a l'air sympathique tout ca... je vais essayer.
  • # Et sinon

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

    Pour ceux qui veulent savoir c'est du python en gpl v3.
    • [^] # Re: Et sinon

      Posté par . Évalué à 1.

      Ca gache tout !!!
      • [^] # Re: Et sinon

        Posté par . Évalué à 1.

        Ouais, la GPL c'est nul. Vive la LGPL !
        • [^] # Re: Et sinon

          Posté par . Évalué à -1.

          Je parlais pas de la GPL, même si je préfère une licence plus libre.
      • [^] # Re: Et sinon

        Posté par . Évalué à 3.

        Prenons ça en main!

        Qui est avec moi pour le recoder en PHP?

        ------------------> [ ]
        • [^] # Re: Et sinon

          Posté par . Évalué à 3.

          Pas mois, désolé, je ne connais que VB6.
          • [^] # Re: Et sinon

            Posté par . Évalué à 3.

            Pas toit ?
            • [^] # Re: Et sinon

              Posté par . Évalué à 1.

              Oups, désolé pour les familles, toussa.
              Dire que je me suis relu 3 fois, la honte.
  • # Dépêche

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

    À la lecture, voilà un petit utilitaire bien alléchant. Et proposer ta prose en dépêche permettrait de le rendre plus visible.
    Tu nous soumets une dépêche ?
    • [^] # Re: Dépêche

      Posté par . Évalué à 7.

      Ultracopier ayant eu son heure de gloire sur DLFP:
      http://linuxfr.org//2010/01/24/26384.html

      ca parait être une bonne idée.

      Et pour vous mâcher le travail

      j'ai «profité» de la perte de ma boîte de vitesse et de me retrouver coincé à Broome (Nord-Ouest de l'Australie... mais ne vous inquiétez pas, je
      ...
      Mais à noter que je ne pourrai pas bosser dessus avant au moins 2 mois.
      Et je finis avec un petit lien vers mes autres projets en cours:
      -lm (list movies): dont j'ai parlé ici: https://linuxfr.org/~Goffi/29966.html , et ...

      Un journal soigné et du bon boulot en tout cas.

      Ca serait pas mal de créer une catégorie "coup de coeur" pour les petits projets qui se lancent.
    • [^] # Re: Dépêche

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

      Wow, 42 commentaires (c'est un signe !) en une nuit, je ne pensais pas a une telle reaction.
      Oui une depeche pourquoi pas, jusque qu'en general je prefere attendre que ce soit vraiment utilisable (c'est la raison pour laquelle je n'ai pas encore propose de depeche pour mon projet principal, sat).
      enfin dans ce cas, c'est deja utilisable en l'etat, du coup je vais proposer si je trouve un moment.

      PS: desole pour les accents, je suis sur un clavier qwerty...
  • # Python ?

    Posté par . Évalué à 6.

    > - gcp ne gère qu'une queue de fichiers: si vous lancer une autre copie, gcp
    > détectera l'autre instance et ajoutera ses fichiers à la première copie. Ainsi
    > ça évitera à la tête de lecture de vos disques durs de faire des ballades tout
    > le temps, et vous pouvez prévoir la fin de la copie plus facilement. Autre
    > avantage: vous pouvez commencer une copie, pendant que vous cherchez d'autres
    > fichiers à ajouter.

    Donc dans le cas où tu fais une copie d'un disque A vers A, et une autre d'un
    disque B vers B, le problème que tu soulèves n'a pas lieu d'être, mais il n'y
    aura qu'une seule copie à la fois ?

    Et puis même, à supposer que je fasse une grosse copie d'un côté, j'aimerais
    pouvoir faire une copie d'un petit fichier de l'autre côté sans attendre que la
    première prenne fin.

    Enfin, est-ce qu'utiliser Python pour gcp ne risque pas d'avoir un impacte
    significatif sur les performances ?

    Il m'aurait semblé qu'un langage de bas niveau eût été plus indiqué pour ce type
    de programme.

    D'autant plus que je lis dans les sources que tu récupères le buffer de 4096
    bytes dans une chaîne python pour l'écrire dans le fichier cible, et qu'entre
    chaque itération tu retourne au watcher glib qui va effectuer à nouveau un appel
    à la méthode python. Je pense que ça a un coût non négligeable.

    Et sinon, je m'interrogeais :

    except KeyboardInterrupt:
    raise KeyboardInterrupt

    Pourquoi tu captures l'instance d'une exception pour en raiser la classe
    équivalente ? :)
    • [^] # Re: Python ?

      Posté par . Évalué à 3.

      Pour les performances, ce genre de programme est fondamentalement I/O bound, donc le choix de Python n'est pas vraiment un problème, vu que la plus grande partie du temps sera passée à attendre que les opérations sur les disques se terminent.
      • [^] # Re: Python ?

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

        Il n'y a pas que les copies inutiles en mémoire à mon avis, il y a aussi ce qui se passe quand tu as des millions de petits fichiers. Ceci dit, je m'avance sans trop de preuves.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: Python ?

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

          Je me réponds à moi-même : déjà s'il y a une file d'attente, avoir des millions de fichiers va complètement exploser la machine. rsync depuis la version 3 arrive à copier des millions de fichiers sans charger tout en mémoire (ça dépend des options cependant).

          DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Python ?

        Posté par . Évalué à 4.

        Tu es peut-être io bound, mais ce n'est pas une raison pour devenir aussi cpu bound.

        "La première sécurité est la liberté"

        • [^] # Re: Python ?

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

          Mon système de sauvegarde est CPU bound actuellement — le RAID5/6 rendant l'écriture et lecture séquentielle relativement rapide, mais le reste est assez lourd (très grand nombre de fichiers, chiffrement, calculs de parité, matériel pas très récent, etc.)

          Donc oui, c'est tout à fait possible d'être CPU bound.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Python ?

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

        Bon, je me lance ;)

        Sur un fichier de 2 GO, après plusieurs lancements pour être *presque* certain que les deux programmes exploitent de la même façon le cache du système, et en flushant le disque avant/après, bla bla,

        En essayant plusieurs taille de *buffer* (ici 16384 Ko), j'obtiens:


        time ./test /tmp/big_file /tmp/big_file2 16384
        ./test /tmp/big_file /tmp/big_file2 16384 0.00s user 1.79s system 14% cpu 12.357 total

        time python test.py /tmp/big_file /tmp/big_file3 16384
        python test.py /tmp/big_file /tmp/big_file3 16384 0.02s user 2.04s system 21% cpu 9.478 total


        Avantage python.

        Bon, ce benchmark n'a aucun intérêt, et des fois j'obtiens 11s pour le python et 10 pour le c ;)

        C:


        #include <stdio.h>
        #include <stdlib.h>

        int main(int argc, char** argv)
        {
        char* file_in = argv[1];
        char* file_out = argv[2];
        size_t buffsize = atoi(argv[3]) * 1024;

        FILE* fr = fopen(file_in, "rb");
        FILE* fw = fopen(file_out, "wb");

        char *buffer = (char*) malloc(buffsize);

        while(1)
        {
        size_t read = fread(buffer, sizeof(char), buffsize, fr);

        if(read == 0)
        break;

        size_t writed = 0;
        while(writed < read)
        {
        writed += fwrite(buffer + writed, sizeof(char), read - writed, fw);
        }
        }

        free(buffer);
        fclose(fr);
        fclose(fw);

        }


        Python :


        import sys

        file_in, file_out = sys.argv[1:3]
        buffsize = int(sys.argv[3]) * 1024

        with open(file_in, 'rb') as fr:
        with open(file_out, 'wb') as fw:
        while True:
        data = fr.read(buffsize)
        if len(data) == 0:
        break
        fw.write(data)


        Bon, mon code C pue certainement... Compilé avec -march=native -Os -Wall

        Sinon, comment on met du code sans pourrir l'indentation sur linuxfr ?
        • [^] # Re: Python ?

          Posté par . Évalué à 3.

          Utilise read/write au moins...

          voir utilise mmap, c'est encore mieux.

          "La première sécurité est la liberté"

          • [^] # Re: Python ?

            Posté par . Évalué à 2.

            mmap pour de la copie de fichier ? Ça apporte quoi ?
            • [^] # Re: Python ?

              Posté par . Évalué à 4.

              Eviter les copies de buffer inutile.

              "La première sécurité est la liberté"

        • [^] # Re: Python ?

          Posté par . Évalué à 1.

          Sinon, comment on met du code sans pourrir l'indentation sur linuxfr ?

          avec des nbsp.
             ta
                ta
                   tada
          • [^] # Re: Python ?

            Posté par . Évalué à 9.

            Pas besoin d'indentation.

            Les vrais hommes programment en assembleur.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Python ?

              Posté par . Évalué à 2.

              50 27 74 69 74 20 6a 6f 75 65 75 72 21 0a

              Il y a 10 types de personnes… :p
              • [^] # Re: Python ?

                Posté par . Évalué à 2.

                ... Les personnes qui savent compter et les autres ?
        • [^] # Re: Python ?

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

          Heu .. pour faire des copies de fichier (en C) on à mieux sous linux quand même: sendfile (et splice ou tee dans des cas d'usages similaires). mmap() peut aussi aider...
    • [^] # Re: Python ?

      Posté par . Évalué à 3.

      Est-ce que tu as moyen de détecter simplement que 2 partitions ne sont pas sur le même disque ?
      Parce que sinon ton optimisation ne marche pas toujours.
      • [^] # Re: Python ?

        Posté par . Évalué à 2.

        À mon avis, c'est impossible d'avoir quelque chose qui marche dans tous les cas, parce que c'est parfois très difficile de savoir sur quel disque se trouvent les données. Exemples :
        - en raid, les données peuvent être sur plusieurs disques
        - LVM complique aussi passablement les choses pour savoir sur quel disque on est
        - il y a aussi le cas des systèmes de fichiers réseau
        - les systèmes montés en loopback
        • [^] # Re: Python ?

          Posté par . Évalué à 3.

          Dans tous les cas, c'est le Device Mapper qui gère ça, il doit y avoir moyen de trouver l'information.

          Par exemple, la commande « # dmsetup deps device » donne les dépendances d'un périphérique, je suppose qu'on doit pouvoir se baser là-dessus.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Python ?

            Posté par . Évalué à 2.

            Pourquoi ne pas se fier au noyau lui même pour savoir ce qui est bon pour le disque ou pas ? Je suppose que le noyau gère par lui même les différents accès disques donc il ne devrait pas avoir lieux de s'inquiéter ?
            • [^] # Re: Python ?

              Posté par . Évalué à 6.

              Si parce que le noyau est con et ne se rend pas compte que l'on se fout d'être égal entre les copies, on veut que l'ensemble se passe très vite.

              Or, si tu fais l'essais de copier 2 ou 3 gros fichiers en même temps, le système va sans cesse faire des mouvements de tête de lecture pour passer d'un fichier à l'autre et baisser de beaucoup le débit final.

              "La première sécurité est la liberté"

              • [^] # Re: Python ?

                Posté par . Évalué à 2.

                Bah, sur les systèmes que je gères, le parcours de la tête de ecture sur le disque on s'en fiche. Vu le nombre de disques dans les baies, si je devais me soucier de ça, je ne m'en sortirais plus. Et de toute façon à partir du moment ou tu mets du LVM, la répartition disque tu ne la maitrise plus, et l'optimisation des accès disque ne se fait plus avec le parcours de la tête, mais plutot dans la répartition de tes données sur ton ensemble de disque (stripe, etc ...).
                • [^] # Re: Python ?

                  Posté par . Évalué à 2.

                  L'optimisation ici est tout de même assez simple.

                  "La première sécurité est la liberté"

    • [^] # Re: Python ?

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

      alors dans l'ordre:

      Donc dans le cas où tu fais une copie d'un disque A vers A, et une autre d'un
      disque B vers B, le problème que tu soulèves n'a pas lieu d'être, mais il n'y
      aura qu'une seule copie à la fois ?


      - oui pour le moment, mais je peux eventuellement faire une option pour desactiver ce comportement (mais c'est a etudier, parce que du coup cq complique pas mal de choses: l'access en concurence aux fichiers de conf, la gestion de la queue a utiliser, etc.


      Et puis même, à supposer que je fasse une grosse copie d'un côté, j'aimerais
      pouvoir faire une copie d'un petit fichier de l'autre côté sans attendre que la
      première prenne fin.

      Utilise cp pour ta deuxieme copie ;)

      Enfin, est-ce qu'utiliser Python pour gcp ne risque pas d'avoir un impacte
      significatif sur les performances ?

      j'ai fait des tests tres rapides, ca a l'air de se tenir avec cp, faut faire des tests plus pousses.

      apres le troll du langage ma passe loin au dessus de la tete: j'ai fait ca pour mon besoin, et python m'a permis de faire ca tres rapidement.

      D'autant plus que je lis dans les sources que tu récupères le buffer de 4096
      bytes dans une chaîne python pour l'écrire dans le fichier cible, et qu'entre
      chaque itération tu retourne au watcher glib qui va effectuer à nouveau un appel
      à la méthode python. Je pense que ça a un coût non négligeable.

      il faut retourner a la glib pour gerer les eventuels appels dbus qu il y a eu entre temps, mais le coup devrait etre negligeable. encore une fois il faut tester, et ajuster les valeurs au besoin.


      Et sinon, je m'interrogeais :

      except KeyboardInterrupt:
      raise KeyboardInterrupt

      Pourquoi tu captures l'instance d'une exception pour en raiser la classe
      équivalente ? :)

      parce que sinon elle sera passe sous silence avec le try except, et que je veux qu'elle soit recupere par le try/except de plus haut niveau. si tu as une meilleure solution je suis ouvert, et les patchs/commentaires sont les bienvenus...
    • [^] # Re: Python ?

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

      >> Enfin, est-ce qu'utiliser Python pour gcp ne risque pas d'avoir un impacte
      significatif sur les performances ?
      >> Il m'aurait semblé qu'un langage de bas niveau eût été plus indiqué pour ce type
      de programme.

      Non, je pense que justement pas.
      C'est typiquement le genre d'applis qui n'a PAS besoin d'être codé en C/C++ ou langage de bas niveau.
      C'est le genre d'applis que t'écris dans un langage de haut niveau pour gérer tout le tralala (les queues, la distribution, l'historique, etc) et qui au final appelle le cp original.

      Il serait idiot, stupide, bête, inepte et con de vouloir utiliser C pour coder ce logiciel. Perte de temps mémorable, et augmentation certaine du nombre de bugs potentiels. Pour un gain plus que négligeable.
      • [^] # Re: Python ?

        Posté par . Évalué à 4.

        Lorsqu’une appli. est destinée à être appelée souvent et ne durer qu’un temps très limité, je trouve au contraire le python pas adapté parce qu’il faut charger tout ce qui est inhérent au language interprété pour exécuter le programme, charger les modules, etc. Sur une machine qui n’a pas trop de RAM, c’est assez rédhibitoire.

        Exemple :

        nicolas:~% time lookback-time>/dev/null
        lookback-time 0,26s user 0,09s system 12% cpu 2,776 total
        nicolas:~% time lookback-time>/dev/null
        lookback-time 0,22s user 0,02s system 100% cpu 0,247 total

        Et après 1 ou 2 minutes :

        nicolas:~% time lookback-time>/dev/null
        lookback-time > /dev/null 0,21s user 0,07s system 28% cpu 1,009 total
        nicolas:~% time lookback-time>/dev/null
        lookback-time > /dev/null 0,19s user 0,06s system 93% cpu 0,266 total
      • [^] # Re: Python ?

        Posté par . Évalué à 3.

        Ca pourrait être intéressant en shell, dans une fonction de ton login shell.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Python ?

        Posté par . Évalué à 1.

        Eh bien non, justement, le programme n'appelle pas cp, il fait les copies lui
        même. Je t'invite à lire mon commentaire attentivement avant de dire des
        conneries.
        • [^] # Re: Python ?

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

          Nan, mais je m'en fous qu'il utilise cp, dd ou cat.
          Mon point, c'est qu'un outil comme celui là à plus besoin d'être pratique que rapide.
          Se dire « oh mon dieux, je dois absolument l'écrire en assembleur pour que les gens le trouvent bien, » c'est con. Si ça amuse certains, tant mieux, hein. Mais c'est un investissement pourri.
          • [^] # Re: Python ?

            Posté par . Évalué à 2.

            Ok donc je vais me répéter parce que tu sembles ne pas comprendre.

            Le monsieur, il ouvre un fp sur le fichier à copier, il ouvre un fp sur le fichier cible, puis il fait des read de 4ko sur le premier pour faire des write sur le second.

            Il ne fait donc pas appel à un autre outil, il fait la copie lui même en python.

            Est-ce que c'est plus clair ou est-ce que j'ai besoin de te montrer son code pour que tu arrêtes de dire n'importe quoi?
            • [^] # Re: Python ?

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

              >> Ok donc je vais me répéter parce que tu sembles ne pas comprendre.

              Ok donc je vais me répéter parce que tu sembles ne pas me lire.
              Et mettre du gras.

              >> Le monsieur, il ouvre un fp sur le fichier à copier…

              Et alors ?
              Je te crois !

              Et j'ai même dit que je m'en cognais, car mon commentaire ne parle *PAS* de ça !

              Tout ce que j'ai dit, c'est que python/perl/lisp n'est pas un mauvais choix pour ce genre d'appli. Tu *PEUX* faire appel à n'importe quel programme/procédure de bas niveau pour gagner des microsecondes si ça te fait plaisir. Si tu veux utiliser des fp à la main, tant mieux !
              Mais pour tout ce qui est autour, la gestion des files, les algos de réplication, la gestion de la ligne de commande, tout ça, le gain en temps de dev, la facilité de compréhension du code, et la clarté du code sont évidents dans un langage de haut-niveau, ce que C n'est pas.
              • [^] # Re: Python ?

                Posté par . Évalué à 2.

                Je pense que tu le fais exprès.

                Donc je te cite, dans ton premier message :

                > C'est le genre d'applis que t'écris dans un langage de haut niveau pour gérer tout le tralala (les queues, la distribution, l'historique, etc) et qui au final appelle le cp original.

                Donc moi ce que je dis, c'est qu'il n'appelle *PAS* d'outil bas niveau optimisé, il fait la copie lui même en python, c'est à dire qu'à chaque fois il lit 4ko, python va créer un objet str, puis l'écrit dans le fichier cible, puis après rend la main à la glib, qui va faire des trucs dbus, puis va réappeler sa fonction, va relire 4ko, etc. C'est à dire que c'est LENT.

                Donc qu'il utilise du python pour tout le cosmetique ne me gêne pas, certaines de mes applications sont en python, ce que je dis simplement, c'est que la copie de fichier est une opération bas niveau, et là il la réimplémente dans un langage haut niveau et interprété.

                J'aurais trouvé ça effectivement plus astucieux d'appeler cp ou quelconque outil optimisé pour la copie de fichiers, mais pas de la réimplémenter lui même dans un langage qui n'est pas prévu pour.
                • [^] # Re: Python ?

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

                  >> Donc moi ce que je dis, c'est qu'il n'appelle *PAS* d'outil bas niveau optimisé,

                  Ben c'était pas clair.
                  Tu me parles de fp, moi, ça m'évoque de la prog système, donc pas du haut-niveau.

                  >> J'aurais trouvé ça effectivement plus astucieux d'appeler cp ou quelconque outil optimisé pour la copie de fichiers,

                  Envoie un patch !

                  >> mais pas de la réimplémenter lui même dans un langage qui n'est pas prévu pour.

                  Bon, ça c'est son problème, plus le notre…
                  • [^] # Re: Python ?

                    Posté par . Évalué à 0.

                    Ok, donc je te montre que j'ai raison et que t'as tort, et pour te dédouaner tu commences par « c'était pas clair », or si ça l'était, je l'ai expliqué dès mon premier commentaire.

                    Tu embrayes sur « envoie un patch », moi je m'en fous je l'utilise pas, je formulais une critique, si tous les habitués de DLFP envoyaient des patches plutôt que de critiquer, Linux serait ready pour le desktop.

                    Et enfin tu termines par « ça c'est son problème, plus le notre », c'est pourtant le sujet du thread.
                    • [^] # Re: Python ?

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

                      J'avais écrit « c'est le genre d'outil que t'écris dans un langage de haut-niveau et qui appelle cp après. »
                      J'ai jamais écrit « le programme de machin utilise cp. »
                      J'ai bien insisté sur le fait que je me tapais complétement des détails d'implémentation, car c'est pas le genre d'application critique qui nécessite une précision au pouillème de microseconde.

                      Tu montes sur tes grands chevaux : « oh, relis moi, il utilise pas cp. »
                      Ça tombe mal, car :
                      J'ai jamais écrit « le programme de machin utilise cp. »
                      J'ai bien insisté sur le fait que je me tapais complétement des détails d'implémentation, car c'est pas le genre d'application critique qui nécessite une précision au pouillème de microseconde.

                      >> si tous les habitués de DLFP envoyaient des patches plutôt que de critiquer, Linux serait ready pour le desktop.

                      Si tous les habitués de DLFP arrêtaient de coder en C, Linux serait ready pour le desktop. Lalala !

                      >> Et enfin tu termines par « ça c'est son problème, plus le notre », c'est pourtant le sujet du thread.

                      S'il a fait son journal, il lit les commentaires, il lit des propositions. Il est assez grand.
                      J'ai pas que ça à foutre non plus. Mon message parlait uniquement du choix d'un langage de haut niveau pour une classe de tâches, mais tu ne m'as pas compris (vu que tu voulais me sortir son code source auquel je ne fais pas référence) et tu me le reproche.
                      Si tu veux continuer, vas-y, j'en aurai pas plus à fiche.
  • # TODO list

    Posté par . Évalué à 6.

    Si tu fais un outils générique de copie, cela peut être sympa d'utiliser des URI (file:// http://...).

    Concernant la queue de copie, cela serait top d'avoir une queue par device. Certe, il y a un couplage pas marrant entre la lecture et l'écriture.

    Concernant la copie elle-même, cela serait top d'utiliser splice()/vmsplice()/tee() pour faire de la zéro copie (ou mmap ?).

    Si tu pouvais faire en sorte que "cp" soit enfin plus rapide que "dd", cela serait super. Les fread/fwrite bufferisent les IO dans un buffer de 64k. Cela fait donc un buffer dans la libc et un buffer dans le noyau (voir 2 avec un read/write classique), soit beaucoup trop de copies.

    De plus, 64K est une taille de bloc beaucoup trop fine, même un raptor à une vitesse qui augmente à 1Mo et audela. Sur du raid, le plateau de vitesse est obtenu avec des tailles d'au moins 16 Mo.

    "La première sécurité est la liberté"

  • # coral bay

    Posté par . Évalué à 0.

    intéressant; je suis jamais allé plus haut que Coral bay ... Avant d'avoir cramé par les rayons du soleil en faisant du snorkelling à ningaloo :-O

    envoyé depuis mon clavier bépo

    • [^] # Re: coral bay

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

      j'y ai crame aussi, malgres la creme solaire ;).
      La on est au debut du printemps (enfin a la fin de la saison seche), et c'est limite insuportable de rester dehors tellement il fait chaud...
      • [^] # Re: coral bay

        Posté par . Évalué à 2.

        Et dedans, ils ne mettent pas la clim trop fort ? Parce qu'aux USA, il y a des coins où quand il fait 40 ° dehors, ils mettent la clim à 18 ° dedans. Ridicule, parce qu'on attrape tout de suite la crève (il pourrait mettre la clim à 25, ça serait pas dramatique).

        Alors si les Australiens, en tant que membres de la grande famille des colonies anglaises, font pareil, ça pourrait aussi être limite supportable de rester dedans en short+t-shirt </mes excuses pour le HS>
        • [^] # Re: coral bay

          Posté par . Évalué à 3.

          Ben en fait, meme quand il fait 19 dehors, ils mettent la clim a 18 dedans.
          J'avais une collegue qui reglait systematiquement la clim de la salle de reunion a 15 degres. A ce niveau la, faut porter une echarpe, une bonnet et des mouffles.

          Et se sont effectivement des feles de la clim, toute l'annee je part bosser avec un pull, pour le porter au boulot. En californie du sud, la ou le plus froid que j'ai vu, c'est 7 ou 8 degres l'hiver, le matin quand il fait encore nuit.

          Et le pire dans tout ca, c'est qu'autant je comprends que t'utilises la clim en arizona quand il fait 45 a 50 toute l'annee, mais par chez moi, c'est 20 a 25 constamment, avec une fraiche (tres fraiche meme) brise du pacifique.

          Sont cons ces ricains...

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: coral bay

            Posté par . Évalué à 3.

            <toujours hs>
            Heureusement que quand on revient en France on peut enlever les pulls dans les bureaux en été :-° </ hs>
            • [^] # Re: coral bay

              Posté par . Évalué à 3.

              Ah bon, ya du monde dans les bureaux l'ete en france?
              'fin je veux dire, des qui bossent, pas des qui font des courses de chaises a roulettes ou des tournois de poubelle-a-pedale-tennis?

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: coral bay

                Posté par . Évalué à 4.

                C’est pour ça qu’il faut bosser en été, patrons et clients sont en congés, on peut se balader en caleçon au bureau.
                Et quand tout le monde rentre, toi tu te casses.

                Depending on the time of day, the French go either way.

  • # rsync

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

    Ah la barre de progression effectivement je l'avais déjà vue apparaître sous Gentoo, mais ça a l'air d'avoir disparu. Je n'avais pas imaginé que c'était un patch tierce-partie.

    Certaines fonctionnalités sont intéressantes (par exemple la copie vers de la FAT, obligation de pas mal de lecteurs audio portables malheureusement). En revanche, certaines me semblent être redondantes quand on les compare à rsync, qui est déjà une sorte de super cp, avec la même compatibilité des options de base. Pourquoi pas essayer d'utiliser rsync comme backend, ou patcher rsync ? :)

    Enfin, pour l'ajout à la liste de copie, comment tu gères le fait qu'on peut avoir plusieurs sources et destinations ? Quand les sources et/ou destinations sont différentes, ce n'est pas forcément intéressant de mettre en queue.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: rsync

      Posté par . Évalué à 3.

      Je crois que l'idée est de faire des petits utilitaires simples et de les proposer à qui veut bien.

      Parcher rsync ca nécessite de se mettre au C, de s'impliquer dans un projet qui n'a pas la même vocation (par ex le renommage de fichiers pour éviter l'écrasement n'est pas trivial en utilisant un outil de synchro)
      Sinon, faire un backend à un programme qui ne propose pas d'API n'est pas forcément du goût de tout le monde (pas du mien en tout cas)
      http://www.mail-archive.com/rsync@lists.samba.org/msg18288.h(...)
      • [^] # Re: rsync

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

        exactement: comme pour lm, c'etait un besoin perso fait en quelques jours, et je propose parce que ca peut servir. mon veritable investissement personnel, c'est dans mon gros projet (sat, client xmpp). Du coup le python ca marche bien, et c'est rapide.

        Pour info je code aussi en C (j'ai meme deja developpe un pilote sous pour nux, cf mon site), mais je n'ai juste pas le temps ni les ressources (le net surtout !) suffisantes en ce moment pour contribuer a rsync.

        En fait bref, ca fait ce que je veux, et je l'ai fait vite.
    • [^] # Re: rsync

      Posté par . Évalué à 4.

      Ah la barre de progression effectivement je l'avais déjà vue apparaître sous Gentoo, mais ça a l'air d'avoir disparu. Je n'avais pas imaginé que c'était un patch tierce-partie.

      Pour avoir une barre de progression, on peut utilise pv : http://www.ivarch.com/programs/pv.shtml
  • # dbus, intelligence

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

    Si tu intègres un service dbus, tu pourras faire toutes les interfaces graphiques que tu veux, et puis avoir des notifications et tout!

    À mon avis, et comme il a déjà été dit, avoir un gestionnaire qui gère de manière intelligente les disques est presque indispensable.
    À savoir, que tu peux potentiellement avoir en parallèle 2 copies si 4 disques sont utilisés (potentiellement des disques réseau montés avec gvfs).
    Il y a aussi les disques SSD, qui ne se préoccupent pas du mode aléatoire.
    • [^] # Re: dbus, intelligence

      Posté par . Évalué à 2.

      Il y a aussi les disques SSD, qui ne se préoccupent pas du mode aléatoire.

      En fait, en pratique si. Le fait que les secteurs d'effacement des flash fasse 128 ou 256 Ko, cela change pas mal de chose(voir les problèmes de "write amplification").

      en pratique, il y a une grosse différence entre accès séquentiel et aléatoire sur un SSD (200Mo/s vs 20Mo/s).

      "La première sécurité est la liberté"

  • # Hors sujet

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

    Humm, excusez moi du hors sujet mais :

    Comment on peut être à Broome, à 2 heures de Cap Leveque et rester scotcher sur un ordi pour faire un journal sur un sombre outil de copie ... si ça c'est pas du dévouement (limite folie) !

    Ça m'en laisse baba :-)

    encore toutes mes excuses, vous pouvez reprendre vos débats constructifs
    • [^] # Re: Hors sujet

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

      S'il pleuvait, il aurait fait comme Linus un projet bien plus prestigieux.

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

      • [^] # Re: Hors sujet

        Posté par . Évalué à 8.

        D'où, par généralisation abusive, une loi universelle qui permet d'expliquer les grandes découvertes par le climat: plus il fait mauvais, plus les gens travaillent à des grands projets, et inversement.

        Maintenant on comprend pourquoi les africains sont tous des lambins et pourquoi les anglais, dotés d'un temps, il faut bien l'avouer, pourri les 9/10 de l'année, rulent the world. C'est logique.
    • [^] # Re: Hors sujet

      Posté par . Évalué à 1.

      La cote ouest est vraiment sauvage, à mettre sur le compte de l'isolement extrême dont il est la victime ^^
      C'est vrai que les Hivers rigoureux finlandais ont largement incité Linus à entendre ce qu'on sait.
      Il m'avait pris l'idée courant 2009 de backpacker en australie puis au fil de mes pérégrinations j'avais acheté un eeepc 901 sous xandros (acheté 450$ australiens)

      Çe fût vraiment une connerie parce que le degré de geekisme qu'il a ramené m'a fait lâcher mon voyage.

      envoyé depuis mon clavier bépo

      • [^] # Re: Hors sujet

        Posté par . Évalué à 3.

        En même temps, les ordis sont parfois beaucoup plus passionnants que le reste... (C'est vrai et faux en même temps, heu, parfois).
    • [^] # Re: Hors sujet

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

      Parce que, comme dit en introduction de journal, j'ai perdu ma boite de vitesse, et je suis coince dans le village (et bon Cable beach et les chameaux c'est sympa, mais au bout d'une semaine tu t'en lasses).

      Et de toute facon, je suis venu en australie aussi pour coder (comme ca ca fait un peu bizarre, mais il y a de vraies raisons derriere)... mais ne t'inquiete pas, je ne me suis pas prive de paysage et autre animaux extraordinaires, et surtout de rencontres...

      Bref, coder et voyager, c'est pas incompatible ;) (et aussi ecrire, discuter, faire la fete, decouvrir, nager, observer, partir en randonnees).
  • # zmv

    Posté par . Évalué à 5.

    Une super feature qui est proposé par zmv et qui mériterait d'être intégrée : la possibilité de modifier les noms de plusieurs fichiers copiés simultanément, par ex :

    > zmv *.JPEG img/*.jpg

    qui va déplacer chacun des fichiers qui se finit par .JPEG et le renommer avec l'extension jpg. Utilisable pour l'instant uniquement par les utilisateurs de zsh, mais peut être qu'il existe un équivalent pour les autres shells?
    • [^] # Re: zmv

      Posté par . Évalué à 2.

      Le mieux serait d'utiliser des regexps, mais le problème étant qu'il ne faut pas
      que le shell les interprète, donc les mettre entre quotes.
      • [^] # Re: zmv

        Posté par . Évalué à 1.

        rename utilise les regexps. Par contre, ça ne doit pas déplacer les fichiers. Mais en bon philosophe unix, il y a mv.
        • [^] # Re: zmv

          Posté par . Évalué à 4.

          Justement, sous Unix le renommage est équivalent à un déplacement (au contraire de DOS où ces opérations sont spécifiques).

          Du coup, si rename peut renommer, il peut forcément déplacer, il suffit de lui donner une commande comme "s/^/dir\//".

          En écrivant ça, j'ai d'ailleurs eu envie de tester, et ça marche.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

Suivre le flux des commentaires

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