Merci les amis !
Alors quelques explications sur le fonctionnement "théorique" de Linux, des programmes tels XtremSplit (version originale) et la différence avec mon script.
J'ai fait des chronométrages avec un fichier de 2GB. C'est en fait un tout petit peu favorable vu que j'ai un PC avec 4GB de RAM et donc lorsqu'on lit et qu'on relit le même fichier, il est en principe tout en RAM. Cela est favorable à XtremSplit, pas trop à mon script qui est bien plus optimisé que ça... mais explication plus bas.
Donc la copie se fait :
- Source (lecture) un disque 2To à 5400RPM (Samsung Spinpoint F4). Fichier situé dans le premier quart du disque (c'est important pour la vitesse). Partition ext4.
- Destintation (écriture) le disque de mon PC Portable, un 5400 RPM. Fichier situé aussi dans le premier quart du disque. Partition ext4.
- MD5 mon processeur est un Corei7 de portable... mais ça dépote quand même pas mal !..
Alors voici les vitesses brutes des éléments séparés.
Pour cela on fait un cp (copie) de la RAM vers le disque (ecriture) ou du disque vers la RAM (lecture). Mon répertoire /tmp est monté en RAM, donc le fichier de 2GB y va pile poil.
Les vitesses brutes sont donc de :
- Lecture = 15,5sec [soit environ 128MB/s, ce qui est confirmé par Palimpsest]
- Ecriture = 19,5sec [soit environ 100MB/s]
- MD5 = 4,9sec [soit environ 400MB/s]
- Copie "à vide" RAM vers /dev/null = 0,4sec [c'est en quelque sorte l'overhead du cp et des filesystems divers]
- Copie disque à disque = 22,5 sec [soit environ 88MB/s, ce qui est cohérent avec l'affichage par exemple lors de copies similaires sous Nautilus]
Protocole de test... linux est super optimisé... si on se contente de faire un cp en mettant un timer avant et après, le résultat est faux. On le constate visuellement en voyant que le disque continue à tourner bien que la ligne de commande ait déjà rendu la main. Et le temps pendant lequel il fait ça n'est pas négligeable !.. En effet, par défaut l'écriture sur le disque est asynchrone. Donc lorsqu'on copie, la commande rend la main lorsque tout est dans le buffer de copie... mais pas encore sur disque. Les buffers pouvant monter à 2GB (facilement sur un système à 4GB), le résultat paraitraît bien plus optimiste si on ne "corrigeait" pas.
La correction consiste donc à placer après le cp des ordres qui vont faire que le système va attendre. Notamment on fait un move (mv) du fichier écrit sur un fichier existant (touch), et on rajoute surtout un sync (synchronisation des buffers)... pour la bonne mesure.
Les temps ci-dessus sont pris avec ces mesures correctrices bien sûr.
Un peut de théorie, on voit alors que Linux est quand même bien optimisé !..
L'overhead du cp n'est que de 2,5% du temps de lecture, mais c'est bien normal, puisque dans notre cas, l'essentiel du temps c'est des I/O, c'est à dire des lectures/ecritures sur disque.
On voit aussi que la copie, bien que j'aie pris la précaution de faire un sync, est très loin de faire la somme de l'écriture et de la lecture. En réalité, par le jeu des buffers, on n'attend pas d'avoir ecrit un bloc pour lire le suivant... on attend juste qu'il soit dans le buffer (sauf le sync final qui vide les buffers d'écriture en l'occurrence).
Alors la théorie, un programme "naïf" tel que l'original XtremSplit (version Windows) va faire la chose suivante :
- Lecture de la source = 15,5 sec
- MD5 = 4,9 sec
- Lecture de la source = 15,5 sec
- Écriture de la destination = 19,5 sec
----------------------------------
- Total théorique = 55,4 sec
Or en faisant tourner Xtremsplit... corrigé du "sync" (car il bénéficie, même si c'est un programme Windows, des mécanismes de bufferisation Linux !)... au mieux 54 sec, soit pas loin du temps théorique !..
Mon script n'utilise pas du tout une démarche aussi naïve et séquentielle, en réalité il fait presque comme une copie, et fait le MD5 en parallèle.
Ca donnerait plutôt :
- Lecture de la source / Ecriture bufferisée (comme un cp) / md5 en parallèle.
Et le résultat est que pour le même fichier, on est à 23,5 sec. On observe bien qu'il y a parallélisation car c'est à peine plus long qu'un cp standard (1 sec) et en tout cas moins long qu'un cp + md5, ce qui ferait 27,4 sec.
La comparaison des performances résumée donne donc :
- Xtremsplit = 54 sec
- Mon script= 23,5 sec
- Copie simple= 22,5 sec
- Copie + MD5= 27,4 sec
Et donc, the--jigsaw, comme te le disais Stavros83, l'essentiel de temps est de toute façon de la copie disque. En l'occurrence, le script met 23,5 sec, là où la copie simple met 22,5 sec. Or la copie simple, si l'on enlève son overhead mesuré plus haut à 0,4 sec, c'est donc à peu près 22 sec de travail sur disque.
On est donc, avec mon script, à 6,5% de calcul (dont le MD5 !) et à 93,5% d'accès disque.
Tu vois donc, et Stavros l'a bien compris, que même si j'écrivais le truc en C/C++, tout au plus tu peux gagner 1 seconde... pas la peine de se fatiguer et de perdre la portabilité du script !..
Franchement, au niveau performance, si tu trouves un truc qui met même pas 5% de plus qu'un cp tout bête, en faisant bien sûr le md5 au passage.... ben tu me fais signe !..
Sur NAS, le temps gagné est encore bien plus considérable. En effet, si tu n'as que l'utilitaire Windows, pour fusionner les fichiers tu dois les passer 2 fois au travers du réseau : lecture, puis écriture. Et donc, sur le cas d'exemple ci-dessus, en supposant que tu as un réseau optimisé 1GB, ça donne facilement 45sec de plus.
Conséquence, tu passes d'un Xtremsplit qui met alors 100 sec, à un script qui met toujours des 23,5 sec... soit cette fois 4 fois plus rapide (au lieu des 2 fois plus rapide standard).
Il en est de même d'un exécutable Linux... à moins de le compiler spécialement pour les NAS.
J'espère que ces quelques mesures t'auront éclairé.
Tu peux bien sûr refaire les mêmes mesures avec les autres programmes, et comparer avec les temps bruts de :
- La copie
- La copie + md5
... et là je pense que niveau performances tu devrais être convaincu !..
(Après il reste bien sûr les limitations de mon script que j'ai énoncées plus haut).
P.S. : bien sûr, la copie avec source et destination sur le même disque physique donne des résultats bien plus mauvais puisqu'à cause des déplacements des têtes dès qu'on passe de lecture à écriture, le processus global est bien plus lent. Quel que soit le programme utilisé, il est donc toujours conseillé de mettre des xtm sur un disque physique, et de faire la fusion sur une destination appartenant à une autre disque physique.
