Alternatives a DD ?

[Grhim]

Salut,

Existe t il une alternative a

Code : Tout sélectionner

dd

en console toujours, et qui soit plus rapide sans passer nécessairement par UnibetBootin ou Balenaetcher etc..

dd ma fait un clone image shdc de 15 Giga en 5h ... (ça me rappelle la gravure cd en 1x )

[Junichirô]

Sous Gnome il y a l'utilitaire disque qui n'est pas mal.

[Grhim]

Sous Gnome il y a l'utilitaire disque qui n'est pas mal.

Merci Juni je teste ça

[MicP]

Bonjour

Tout dépends de tout : les spécifications de la machine sur lequel tourne le système, la façon dont elle est configurée, les périphériques utilisés, les supports utilisés (source et cible) le système de fichiers utilisé sur ces supports, la disponibilité du système ( <=> s'il n'y a que la copie en cours ou bien s'il y a blender qui est en train de faire des calculs et en même temps plusieurs téléchargements en P2P), etc...

Mais là, on n'a que très peu d'informations : la commande dd et "un clone image shdc de 15 Giga en 5h" (j'avoue d'ailleurs que je ne sais pas du tout ce qu'est shdc).

=======
La commande dd a plein d'options possibles, dont la taille des blocs utilisés en lecture ou/et écriture (bs ibs obs)
qui, paramétrées avec les "bonnes valeurs", permettront très certainement de réduire la durée effective de la copie.

Par défaut, dd utilise une taille de blocs de 512 octets

Sur ma machine et vers mes clefs USB, j'obtiens généralement un assez bon résultat
en mettant 4 Mio comme valeur à l'option bs

Code : Tout sélectionner

dd if=/dev/periphSource of=/dev/periphCible bs=4M status=progress && sync

La commande finale sync me permet d'être sûr que, quand le prompt de retour s'affiche,
tout a effectivement été copié sur le périphérique cible.

Pour une copie d'un SSD vers un autre SSD,
j'ai eu souvent de meilleurs résultats en mettant l'option bs à 16Mio

=======
J'ai remarqué que GParted, avant de lancer une copie effective (peut-être seulement quand c'est vers un autre support),
fait plusieurs test de copie avec des valeurs de taille de blocs différentes afin d'essayer de trouver cette "bonne valeur" de taille de bloc qui dépend du contexte.

[dezix]

Salut!

La commande finale sync me permet d'être sûr que, quand le prompt de retour s'affiche,
tout a effectivement été copié sur le périphérique cible.

Apparemment, l'option : conv=fdatasync
évite une seconde commande.

Extrait du manuel :

fdatasync : écrire les données du fichier de sortie physiquement avant de terminer.

[Grhim]

Bonjour

Tout dépends de tout : les spécifications de la machine sur lequel tourne le système, la façon dont elle est configurée, les périphériques utilisés, les supports utilisés (source et cible) le système de fichiers utilisé sur ces supports, la disponibilité du système ( <=> s'il n'y a que la copie en cours ou bien s'il y a blender qui est en train de faire des calculs et en même temps plusieurs téléchargements en P2P), etc...

Mais là, on n'a que très peu d'informations : la commande dd et "un clone image shdc de 15 Giga en 5h" (j'avoue d'ailleurs que je ne sais pas du tout ce qu'est shdc).

j'ai écris vite mais c'est sdhc (micro card sandisk)

[MicP]

…Apparemment, l'option : conv=fdatasync
évite une seconde commande.
…

Effectivement, je viens de tester cette option qui a fonctionné aussi bien que l'ajout de la commande sync

=======
On ne sait pas quelle est la source de la copie, mais s'il s'agit d'un support dont un ou plusieurs des systèmes de fichiers est en cours d'utilisation <=> système de fichiers monté(s)
(et même chose pour la cible) alors il se peut que ce soit la cause du problème.

Je viens de faire plusieurs tests, et le plus long a duré 35 minutes pour faire une copie d'un fichier de 16GB
vers une clef USB 2 (directement sur le fichier de périphérique associé à la clef de 16GB <=> pas sur une partition de la clef USB ni sur un système de fichiers qui serait contenu dans une des partition)

[Grhim]

=======
On ne sait pas quelle est la source de la copie, mais s'il s'agit d'un support dont un ou plusieurs des systèmes de fichiers est en cours d'utilisation <=> système de fichiers monté(s)
(et même chose pour la cible) alors il se peut que ce soit la cause du problème.

Haaaa !! pas bête , je vérifierais, c'etait peut être ça ....

La source c'est microSD 16 Giga sandisk sur lecteur multicarte vers img locale