Alternatives a DD ?

On y discute de tout, ou presque...
Répondre
Avatar de l’utilisateur
Grhim
Membre très actif
Membre très actif
Messages : 1370
Inscription : 30 mai 2016, 01:00
Localisation : kekparr'par'là
Status : Hors-ligne

Salut,

Existe t il une alternative a 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 ... :dirol: (ça me rappelle la gravure cd en 1x :lol: )
Avatar de l’utilisateur
Junichirô
Membre actif
Membre actif
Messages : 971
Inscription : 26 avr. 2016, 01:10
Localisation : Baillif (Guadeloupe)
Status : Hors-ligne

Sous Gnome il y a l'utilitaire disque qui n'est pas mal.
“Lorsque vous avez éliminé l’impossible, ce qui reste, si improbable soit-il, est nécessairement la vérité.”
Avatar de l’utilisateur
Grhim
Membre très actif
Membre très actif
Messages : 1370
Inscription : 30 mai 2016, 01:00
Localisation : kekparr'par'là
Status : Hors-ligne

Junichirô a écrit : 15 nov. 2022, 17:44 Sous Gnome il y a l'utilitaire disque qui n'est pas mal.
Merci Juni :023: je teste ça
MicP
Modérateur
Modérateur
Messages : 896
Inscription : 16 avr. 2016, 22:14
Status : Hors-ligne

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.
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Salut!
MicP a écrit : 19 nov. 2022, 03:23 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.
**Simple Utilisateur** -- Debian stable - XFCE
Avatar de l’utilisateur
Grhim
Membre très actif
Membre très actif
Messages : 1370
Inscription : 30 mai 2016, 01:00
Localisation : kekparr'par'là
Status : Hors-ligne

MicP a écrit : 19 nov. 2022, 03:23 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) :003:
MicP
Modérateur
Modérateur
Messages : 896
Inscription : 16 avr. 2016, 22:14
Status : Hors-ligne

dezix a écrit : 19 nov. 2022, 09:17 …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)
Avatar de l’utilisateur
Grhim
Membre très actif
Membre très actif
Messages : 1370
Inscription : 30 mai 2016, 01:00
Localisation : kekparr'par'là
Status : Hors-ligne

MicP a écrit : 20 nov. 2022, 03:56

=======
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.
:shout: 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 :023:
Répondre