Hello
Je voudrai cloner mon disque ssd , seulement je fesai cela avec dd ,mai je ne suis pas certain que c’est outil soie aussi prevu pour cloner un disque ssd ?
mes donnée son quand même fait avec tar, mai bon pour éviter de ce taper des probleme avec le F.S j’aimerai aussi pourvoir faire un clonage complet ?
Merci d’avance 
Pourquoi dd ne fonctionnerait-il pas avec un disque SSD ? C’est un périphérique bloc au même titre qu’un disque dur classique.
si le ssd doit être utilisé au mieux, géométrie, alignement, etc. dd n’est pas forcément la meilleure solution. Voir aussi un problème de taille qu’il faudra retoucher.
tar semble plus indiqué.
Ce n’est pas spécifique aux disques SSD. Il faudrait que panthere précise ce qu’il entend par “cloner” et pour quelle finalité.
Quand j’ai changé mon disque pour un ssd je n’ai pas trop réfléchis : j’ai créé mes partitions, fait un rsync des donnés et réinstallé grub dessus. Bon ensuite j’ai optimisé légèrement l’os pour fonctionner sur un SSD mais rien de bien sorcier 
[quote=“cepcasa”]si le ssd doit être utilisé au mieux, géométrie, alignement, etc. dd n’est pas forcément la meilleure solution. Voir aussi un problème de taille qu’il faudra retoucher.
tar semble plus indiqué.[/quote]
+1 pour l’alignement, c’est la ou dd pourrait justement ne pas pouvoir restaurer comme il ce doit. 
PascalHambourg:
par clonage il s’agi de tout copier, aussi bien le fs que les donnée etc .cloner resume bien cela l’avantage de dd c’est qu’il est fiable et permet de faire un fichier tar du disque , compressible par la suite avidement.
mai bon la je ne sai pas trop quoi utiliser.
Je ne vois pas la différence par rapport à un disque classique… Globalement, tu as juste un paquet de blocs à conserver et dd me parait bien pour ça. Cela dit, sauf pour la structure du disque, tar ou cpio conviennent très bien pour conserver un backup complet.
si le disque ssd a été, ou doit être géré comme un disque classique il n’y en aura pas, bien sûr.
Par contre si on veut gérer au mieux le ssd, l’aligner, gérer au mieux le trim, dd va bien compliquer tout cela, recopiant la totalité de la situation du disque classique, géométrie, état du fs avec ses trous, bref toute la pagaille.
Dans ce cas à quoi bon utiliser un ssd . . . si c’est pour cloner à l’identique d’un disque classique, dont on ne connait même pas la techbologie ni l’état du fs et de sa fragmentation.
Bref, pour utiliser au mieux cette technologie tar est tout indiqué.
Un disque SSD se moque de la fragmentation puisqu’il n’y a aucun délai pour accéder à un bloc. Où alors c’est beaucoup plus subtil que je ne le pensais et je ne vois plus du tout l’intérêt de ce truc.
La commande trim est juste une optimisation, en gros le SSD efface un fichier effacé de lui même ce qui accélère l’écriture lors d’une écriture ultérieure (si j’ai bien compris), en clair on balance au controleur SSD une liste de blocs effacés et celui gère ça pendant son temps libre. Je ne vois pas trop le rapport avec dd ni pourquoi en quoi une recopie brutale de partition empêcherait son fonctionnement. Le SSD n’est tout de même pas dépendant du système de fichiers qui est dessus, il faut juste que les systèmes d’exploitation sachebt exploités ces fameuses commandes TRIM et tirent partie de l’égal accès à tous les blocs du disque (entre autres, on se moque de la fragmentation désormais…)
sauf que tu lui balances l’ensemble brut d’une situation existante au niveau du fs, et ce sans avoir au préalable réorganisé l’espace non utilisé du fs à cloner, obliger le trim à travailler sur l’ensemble. Sans oublier’une géométrie qui ne lui convient pas forcément, même très certainement pas.
Pour terminer, je ne comprends pas cette volonté d’utiliser une solution bancale, presque brut force 
alors qu’il en existe d’autres, plus souples et adaptées aux ssd, comme par exemple parted et l’option -a puis le mkfs.?? avec les bonnes options, tar, et enfin le mount toujours avec les options au mieux, sans oublier éventuellement suivant l’utilisation et le but recherché (performances ou sécurité), d’adapter le scheduler dans /sys/block/sd?/queue/scheduler.
[quote=“cepcasa”]sauf que tu lui balances l’ensemble brut d’une situation existante au niveau du fs, et ce sans avoir au préalable réorganisé l’espace non utilisé du fs à cloner, obliger le trim à travailler sur l’ensemble. Sans oublier’une géométrie qui ne lui convient pas forcément, même très certainement pas.
Pour terminer, je ne comprends pas cette volonté d’utiliser une solution bancale, presque brut force 
alors qu’il en existe d’autres, plus souples et adaptées aux ssd, comme par exemple parted et l’option -a puis le mkfs.?? avec les bonnes options, tar, et enfin le mount toujours avec les options au mieux, sans oublier éventuellement suivant l’utilisation et le but recherché (performances ou sécurité), d’adapter le scheduler dans /sys/block/sd?/queue/scheduler.[/quote]
surment, pour le tar c est fait m’enfin l’interet du dd c est de pas ce casser la tête a savoir si tout est bien present , certe brutal m’enfin je suis une brute 
j’aime pas trop utiliser plusieur outils a la fois car sa diminue la fiabilité d’une sauvegarde dans le sens ou le risque de bug par rapport aux nombre de logiciel augmente . bien que ceux ci on fait leur preuve mai pas forcement a jour, on a donc l’exemple tout simple avec dd a présent
Merci pour vos réponse je pense que ce topic va intéresser du monde
P.S je déménage je risque d’être un peux lent aux réponse (en plus d’être suisse )
Quel est le lien entre le trim et l’organisation? Le trim est un effacement a priori d’un bloc (d’une cellule) avant une écriture. Cet effacement peut être fait juste avant l’écriture (méthode sans optimisation) ou bien lorsqu’on sait qu’un bloc doit être libéré donc lors de l’effacement d’un fichier (commande trim). Donc le trim n’a rien à voir avec la structure de ce qu’on écrit sur un disque. C’est une préparation du disque possible lorsqu’on a une organisation existante sur le disque lors de son utilisation.
De même la géométrie sur un SSD est quelque chose de purement logiciel, ça n’est qu’une cartographie artificielle afin d’adresser un espace mémoire dont de toute façon le temps d’accès est indépendant de la localisation.Là encore ça n’a aucun intérêt. Pour ClefAgreg j’ai différentes géométrie sur une clef USB, la seule différence était la faculté pour un BIOS de la bouter ou non.
Par contre, deux points où l’objection est valable, c’est que d’une part,un dd fait un cycle d’écriture sur tous les blocs du SSD or le nombre d’écritures maximum sur une cellule de SSD, si il ne se compte plus en dizaine de milliers reste entre 500000 et 1 à 2 millions pour les plus solides. C’est donc une manoeuvre à ne pas répéter sans arrêt. D’autre part l’ensemble des cellules du SSD a été réécrit donc le gain à l’écriture du à la commande TRIM ne se fera sentir qu’après une période de mise en route. Peut être est ce cela que tu voulais dire.
Cela dit, encore une fois si il s’agit d’un simple backup, un tar ou équivalent est beaucoup plus simple et n’a guère d’inconvénient, le dd est intéressant si on veut un clone du disque rapidement et sur.
il y a plusieurs technologies ssd, bien sûr.
Alors le trim. Il est tributaire des informations de l’os, qui lui donne des indications sur l’état d’un fichier, présent ou effacé (à effacer). Or dd va faire une écriture continue, bit à bit. Comment va réagir le trim ? il va se mélanger les pinceaux sur certains blocs ? rétablir la situation ou le secteur sera effacé au moment de l’écriture de nouvelles données ? c’est ce que tu signales justement par :" le gain à l’écriture du à la commande TRIM ne se fera sentir qu’après une période de mise en route ". Si tant est que le trim ait pu rétablir la situation sur l’ensemble du disque. Comme dit plus haut, ne pas oublier que le trim reçoit sa commande lors de la suppression du fichier. Vient s’ajouter une complication, le système de fichiers utilisé. Très clairement avec ext4 il s’en sortira mieux que ext2, voir même ext3. Quid par exemple de btrfs ? si l’optimisation ssd n’avait bien sûr pas été faite, voir aussi les autres options, dont l’utilisation ou non de -m single et l’option -o de mount pour les ssd.
Voir aussi certains tests faits sur des ssd avec écriture séquencielle puis suppression de la partition. Le ssd n’avait pas retrouvé ses capacités initiales tant qu’un nouveau fs n’avait pas été créé.
Tu écris :[quote]" De même la géométrie sur un SSD est quelque chose de purement logiciel, ça n’est qu’une cartographie artificielle afin d’adresser un espace mémoire dont de toute façon le temps d’accès est indépendant de la localisation.Là encore ça n’a aucun intérêt. Pour ClefAgreg j’ai différentes géométrie sur une clef USB, la seule différence était la faculté pour un BIOS de la bouter ou non."[/quote]
Je ne comprends pas ta remarque. Cela n’a rien à voir avec le fait qu’il soit bootable ou non. À la rigueur pour une clé usb en effet comment certains bios vont la gérer, comme une disquette, un disque lba, etc. Mais là il s’agit aussi de savoir comment et où vont être adressées les écritures, sur quelle page et quelle taille de page. Doit-il rester aussi sur du 512 o comme va le lui imposer dd ?
À ce sujet je te renvoie sur ce qu’écrivait Théodore T.so ici :
thunk.org/tytso/blog/2009/02/20/ … lock-size/
Le tout complqué par le fait qu’il y a plusieurs types de ssd, slc, mlc. Et je ne parle même pas de la gestion de la taille du disque par dd.
Pour l’alignement, voir par exemple les options de parted :
-a alignment-type, --align alignment-type
Set alignment for newly created partitions, valid alignment types are:
none : Use the minimum alignment allowed by the disk type.
cylinder : Align partitions to cylinders.
minimal : Use minimum alignment as given by the disk topology information. This and the opt value will use layout information provided by the disk to align the logical partition table addresses to actual physical blocks on the disks. The min value is the minimum aligment needed to align the partition properly to physical blocks, which avoids performance degradation.
optimal : Use optimum alignment as given by the disk topology information. This aligns to a multiple of the physical block size in a way that guarantees optimal performance.
Là je te rejoints totalement.
Non, ce qui serait intéressant, c’est de tester les capacités d’un ssd après un tar et après clonage par dd. Dommage, je n’ai pas de ssd disponible.
Copier d’où vers où, et pour quelle finalité ?
D’un disque SSD vers un fichier image ?
D’un disque dur vers un disque SSD ?
D’un disque SSD vers un autre disque SSD ?
Pour archiver/sauvegarder ou dupliquer/remplacer le disque ?
Je ne vois pas où est le problème, ça ne fera jamais qu’un cycle d’écriture sur les 500000. Même si on le fait 1000 fois, ça ne fera jamais que 1000 cycles sur les 500000, soit 0,2%.
Question concernant le trim : quand il y a des couches intermédiaires entre le système de fichiers et le disque (LVM, RAID…), est-ce que celles-ci font suivre l’information de trim ?
bjr a tous
& clonezilla partimage pourquoi pas pour ne cloner que les secteurs occupés??
[quote=“PascalHambourg”]
Je ne vois pas où est le problème, ça ne fera jamais qu’un cycle d’écriture sur les 500000. Même si on le fait 1000 fois, ça ne fera jamais que 1000 cycles sur les 500000, soit 0,2%.
Question concernant le trim : quand il y a des couches intermédiaires entre le système de fichiers et le disque (LVM, RAID…), est-ce que celles-ci font suivre l’information de trim ?[/quote]
Il me semble que le trim est juste une instruction supplementaire du controleur: l’OS lui signale que le secteur tant est à effacer. Pour cela il faut qu’il y ait une structure de fichiers (afin que la notion «à effacer» est un sens), que l’OS sache le faire (linux et W7 pour le moment) et il faut que le controleur puisse retransmettre l’info au disque. Ça n’est pas si simple.
Pour ta remarque sur l’écriture, c’est exact mais bon, un usage intensif des clefs USB m’a fait cramer 6 clefs en quelques mois alors que je ne faisais pas tant d’écriture que ça (ça n’est que lorsque j’ai abandonné le principe d’un home sur clef USB que le massacre s’est arrêté). Je suis donc devenu sensible à ce problème et suis assez sceptique sur la fiabilité des SSD. J’ai donné les chiffres usuellement retenu par honnêteté intellectuelle mais je n’y crois qu’à moitié. Cela dit un seul cycle d’écriture ne change rien, tu as raison…
Il me semble que le nombre de cycles d’écriture d’un SSD est très supérieur à celui d’une clé USB. L’algorithme d’égalisation de l’écriture des SSD doit y être pour quelque chose.
C’est sur que la plupart du temps, la Clef USB est systématiquement réécrite au niveau du bloc correspondant à la racine. Cette répartition est faite au niveau de l’OS ou au niveau du controleur?
[quote=“clahor”]bjr a tous
& clonezilla partimage pourquoi pas pour ne cloner que les secteurs occupés??[/quote]
j’ai tester ces soft, et j’ai eu des mauvaise surprises. je passe les détail du pourquoi du comment (trop loin pour m’en souvenir exactement)
c’est pour dupliquer le disque, disque <-> disque ssd comme disque sata.
la j’ai ma config qui tourne impec, je voudrai la clonner sur un portable, je passe donc par un disque externe qui possede un branchment sata ,mai aussi usb
je passe donc par une image disque, dd permaittait de faire cela sans ce casser la tête 
une foit le clone fait j’archivai en utilisant bzip2
simple mai efficace.
a propos j’ai de nouveau un disque sataII qui vien de me claquet dans les doigt juste après la garentie grrrr 
hitachi deskstart 250gb, bon je peux toujours recupérer les plateau pour faire de dessous de verre a bière, et les aimant pour les enfant ou les future portes :
par contre c’est blinder et j’ai pas le tournevis qu’il faut