{"partition": "head_middle", "source_domain": "forum.ubuntu-fr.org", "digest": "sha1:VEWDFM6FDOLK6V2BEYBEZR4SQKRQKSNP", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00006.parquet"}
» LinCopier - Gestionnaire de copies pour Linux
Revan26914
Re : LinCopier - Gestionnaire de copies pour Linux
On dirait bien Dernière modification par Revan26914 (Le 17/11/2010, à 16:55)
Mon blog - Mon site perso
Brunod
Quoi d'neuf, Doc ?
Windows est un système d'exploitation de l'homme par l'ordinateur.Linux, c'est le contraire ... --> état de la conversion : 34 pc linux
up ... ?
Rolinh
Salut,on manque cruellement de temps en ce moment (études universitaires + boulot) J'espère que l'on trouvera le temps de bien avancer pendant ces vacances de noël.Pour donner une info quand même, Revan a comparé le moteur de copie de LC et celui de cp. Résultat: soit a égalité soit plus performant.L'idée (piquée à NetBSD) de maper en mémoire les fichiers de moins de 8mb se révèle diablement efficace sur les petits fichiers Blog"If you put a Unix shell to your ear, do you hear the C ?"
De tout cœur avec vous Mais impatient quand même ! BD
ça fait sacrément plaisir des encouragements pareils d'ailleurs, je passe le message: on aurait besoin de quelqu'un pour faire le GUI en GTK. Enfin besoin... c'est juste que cela nous permettrait d'avancer un peu plus vite. J'ai commencé à faire quelque chose mais depuis je me concentre sur l'interface de la version console tandis que Revan s'occupe du moteur de copie. Sinon je m'y remettrais mais... GTK c'est pas mon fort.Car en fait, on a décidé de faire une version console et une version GTK. D'abord, la console c'était pour tester le moteur de copie puis on s'est dit que ça serait quand même vachement pratique si, par exemple, on veut faire des copies massives sur son serveur en étant connecté en SSH. Ou bien tout simplement si on est allergique aux interfaces graphiques... Blog"If you put a Unix shell to your ear, do you hear the C ?"
Zakhar
@Brunod, @Revan... discussion intéressante sur les "performances" maximales !Mais en réalité il n'y a pas de "meilleur" truc, tout dépend du "use case" (cas d'utilisation), notamment son matériel et ce qui est le "maillon faible".J'avais réalisé un moteur de copie optimisé sur CTOS (un O.S. hélas disparu)... il y a une vingtaine d'années !.. Et pour le "use case" à l'époque c'était fort intéressant par rapport à la copie basique du système.Que se passe-t-il dans un programme de copie "naïf" (comme celui de Windows... et d'où l'intérêt de SC sur Windows), lorsqu'on copie un fichier :Début :
- Lecture bloc fichier source
- Ecriture bloc fichier destination
=&gt; tant qu&#039;il reste des octets à écrire, retourner à début.... et voila ! Ça s'appelle de la copie en série. Et c'est raisonnablement efficace dans 90% des cas où on copie un fichier d'un disque sur lui-même.Simplement ce même algorithme s'avère largement sous-optimisé lorsqu'on copie entre plusieurs périphériques différents : disque à disque, disque à clé USB, disque à disque via réseau, etc...Pour comprendre pourquoi il faut descendre au niveau physique de la chose.Commençons par le cas simple :- Copie d'un fichier d'un disque physique sur lui-même :On suppose qu'il s'agit là d'un disque physique magnétique avec des plateaux et des têtes de lecture.L'opération de copie va donc nécessiter de déplacer la tête à l'endroit à lire, lire un bloc, déplacer la tête à l'endroit à écrire, écrire un bloc, etc... jusqu'à ce qu'on ait fini la copie.Le temps CPU est négligeable (une boucle simple, et des DMA pour lire/écrire) et donc le "maillon faible" en l'occurrence est le disque physique qui va devoir lire/écrire et déplacer les têtes.Les optimisations que l'on peut faire dépendent de la taille des fichiers.Sur les gros fichiers, il n'y a pas grand cho