Remise à zero disque dur par DD

brazz · Le 14/10/2019, à 14:15

Bonjour,
devant me séparer de mon NAS, j'ai voulu "remettre à zéro usine" les disques.
Ce sont des 2 To SATA; pour cela j'ai fait un bête

sudo dd if=/dev/zero of=/dev/sde

sans penser à faire afficher la progression
c'était il y a 4 heures et en apparence ça continue !
est ce normal, je n'ai rien trop trouvé sur les durées de ce genre de chose...
désolé de ma bêtise

rmy · Le 14/10/2019, à 14:55

Ça dépend du modèle de ton disque principalement, ça devrait tourner entre 80Mo/s et 180Mo/s en très grossièrement.

Compte 5h par disque.

Pour plus de suivi et vérifier qu'il n'y a pas d'erreur, tu peux aussi utiliser

ddrescue

Tu peux aussi interrompre ton "dd" avec Ctrl+C et le prompt devrait t'afficher quelle quantité de zeros ont été copiés jusqu'à présent, et reprendre avec ddrescue en utilisant -i size, pour faire démarrer là où tu en étais.

Dernière modification par rmy (Le 14/10/2019, à 14:56)

brazz · Le 14/10/2019, à 17:33

Merci,
en utilisant

dd if=/dev/zero | pv | sudo dd of=/dev/sde

j'ai déjà constaté que ma première erreur avait été d'utiliser ma vieille docking station(de Bluestork)
qui est donc externe et communique par USB !

vitesse d'écriture 5Go -> 18 mn !!!
ce qui nous donne pour 1 To ... on pleure !!!!

j'ai donc remplacé un disque interne de mon PC par celui que je voulais remettre à zéro, et j'ai recommencé.
il y a du mieux, mais :
vitesse d'écriture 5Go -> 3.15 mn
et pour 1 To ça me ferait donc 1000 heures quand même !
pardon 10 heures...

Je n'avais pas pensé à ce genre de problème jusqu'ici, mais je pense que ce n'est pas trop possible ainsi.
le Wiki n'est pas trop prolixe sur les solutions, je ne sais pas comment font les hébergeurs quand ils changent de disques, il ne doivent quand même pas jeter les leurs, ni passer des jours !
il doit donc y avoir d'autres méthodes.

Je vais chercher.
Mais si quelqu'un a des tuyaux je serais assez preneur, d'ailleurs finalement ça peut concerner du monde car il est courant de changer de disque pour une plus grosse capacité et il est inutile de remplir les caves (quand on en a, il y a mieux à y mettre ) en plus avec le temps on a maintenant assez couramment des disques de 8 To ....
Voilà typiquement le genre d'outillage qu'on serait content de trouver en changeant de version d'Ubuntu !
Mais ce que j'en dis...

Dernière modification par brazz (Le 14/10/2019, à 17:43)

brazz · Le 14/10/2019, à 17:36

A propos de cave, il faudrait que j’arrête avec mes 1000 heures ! n'importe quoi !
De toutes façons, avec du 30 Mo/s (au lieu de 80 à 180) manifestement mon matos est comme moi,
il a vieilli et il va falloir penser à changer...C'est le point positif de cela de l'avoir constaté.
Mais c'est bien long quand même, il doit y avoir mieux....

Dernière modification par brazz (Le 14/10/2019, à 18:23)

kamaris · Le 14/10/2019, à 18:55

Il faut que tu fasses quelques tests en faisant varier la valeur de bs dans dd.
Tu copies quelques gigas (ou même moins) et tu vois ce que ça donne comme vitesse de transfert, tu devrais vite pouvoir remonter ton 30 Mo/s à une valeur plus acceptable.

Dernière modification par kamaris (Le 14/10/2019, à 18:56)

rmy · Le 14/10/2019, à 20:49

brazz a écrit :

Merci,
en utilisant
dd if=/dev/zero | pv | sudo dd of=/dev/sde
j'ai déjà constaté que ma première erreur avait été d'utiliser ma vieille docking station(de Bluestork)
qui est donc externe et communique par USB !
vitesse d'écriture 5Go -> 18 mn !!!
ce qui nous donne pour 1 To ... on pleure !!!!

j'ai donc remplacé un disque interne de mon PC par celui que je voulais remettre à zéro, et j'ai recommencé.
il y a du mieux, mais :
vitesse d'écriture 5Go -> 3.15 mn
et pour 1 To ça me ferait donc 1000 heures quand même !
pardon 10 heures...

Je n'avais pas pensé à ce genre de problème jusqu'ici, mais je pense que ce n'est pas trop possible ainsi.
le Wiki n'est pas trop prolixe sur les solutions, je ne sais pas comment font les hébergeurs quand ils changent de disques, il ne doivent quand même pas jeter les leurs, ni passer des jours !
il doit donc y avoir d'autres méthodes.
Je vais chercher.
Mais si quelqu'un a des tuyaux je serais assez preneur, d'ailleurs finalement ça peut concerner du monde car il est courant de changer de disque pour une plus grosse capacité et il est inutile de remplir les caves (quand on en a, il y a mieux à y mettre ) en plus avec le temps on a maintenant assez couramment des disques de 8 To ....
Voilà typiquement le genre d'outillage qu'on serait content de trouver en changeant de version d'Ubuntu !
Mais ce que j'en dis...

C'est sur que par l'usb 2 le facteur limitant c'est 30Mo/s.
dd n'est pas optimisé, la taille de blocs par défaut est ridicule.
La solution, je te l'ai donnée :

sudo ddrescue /dev/zero /dev/sde -nvvf

Fais comme tu veux ;-)

(oui, j'ai 100To de disques que j'utilise et formate wipe régulièrement à la cave) (en vrai)

EDIT : sinon tu as hdparm --security-erase mais c'est pas plus rapide. C'est juste une routine interne du DD…

Dernière modification par rmy (Le 14/10/2019, à 20:52)

brazz · Le 15/10/2019, à 06:08

Merci à rmy et kamaris,

en fait je suis un vieil imbécile !

en paramétrant correctement les choses, voilà ce que ça donne:
le fdisl -l me donne des secteurs de 512, c'est pourquoi je prends cette valeur en bs
d'où un :

sudo  dd  if=/dev/zero  of=/dev/sdd bs=512k status=progress

et là j'ai bien une remise à zéro des 2 To en 4 heures...

rmy · Le 15/10/2019, à 06:40

bs=512k c'est différent de bs=512…
Mais l'idée est là, en prenant plusieurs secteurs d'un coup tu exploites mieux le cache. Suivant ton disque tu peux aller probablement à une valeur de 32/64M.

Et une fois encore, pourquoi utiliser dd, alors que ddrescue fait ça tout seul, et avec un affichage en temps réel ?

Tu peux passer ton sujet en Résolu…

Dernière modification par rmy (Le 15/10/2019, à 06:41)

kamaris · Le 15/10/2019, à 11:27

Oui voilà, c'est par rapport au cache. Perso, avec un cache de 8 Mio (mon disque n'est pas tout jeune), mes tests m'avaient conduit à prendre 4 Mio (donc bs=4096) comme valeur « optimale ».

rmy · Le 15/10/2019, à 12:50

kamaris a écrit :

4 Mio (donc bs=4096)

tu veux probablement dire bs=4096K

kamaris · Le 15/10/2019, à 13:58

Oui bien sûr, tu as raison, pour 4 Mio ça aurait été 4096K ou 4M, et pas 4096 tout court.
Sauf que… c'est bien 4096, ou 4K, que j'avais retenu comme valeur (j'ai gardé des logs que je viens de vérifier).
Donc j'avais bien regardé le cache de mon disque à l'époque, pensant qu'il devait y avoir un lien, mais ce sont bien des tests d'écriture qui m'avaient fait retenir une valeur, laquelle n'est peut-être finalement pas si liée au cache que cela, ou pas que…
Bref, ce que j'avais retenu à l'époque et que je retiens encore aujourd'hui, c'est qu'il faut faire des tests !

rmy · Le 15/10/2019, à 14:03

Moi ce que j'en retiens, c'est qu'il n'est pas utile de faire du feu avec un baton et de la paille quand on a un briquet, ni d'utiliser un silex quand on a un couteau…

ddrescue

kamaris · Le 15/10/2019, à 14:17

Certes, surtout qu'on arrivera jamais à atteindre l'agilité qu'avaient les hommes préhistoriques avec ces techniques :

kamaris · Le 15/10/2019, à 19:35

Bon, trêve de plaisanteries : comme je n'avais conservé que cette valeur de 4096 pour bs, j'ai refait quelques tests pour voir.
Voici tout d'abord les caractéristiques de mon disque :

$ sudo hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
	Model Number:       TOSHIBA MK6476GSX                       
	Serial Number:      523CPCBJT
	Firmware Revision:  GS001C  
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
	Supported: 8 7 6 5 
	Likely used: 8
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:    16514064
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:  1250263728
	Logical  Sector size:                   512 bytes
	Physical Sector size:                   512 bytes
	device size with M = 1024*1024:      610480 MBytes
	device size with M = 1000*1000:      640135 MBytes (640 GB)
	cache/buffer size  = 8192 KBytes
	Form Factor: 2.5 inch
	Nominal Media Rotation Rate: 5400
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Advanced power management level: 128
	DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	   *	Advanced Power Management feature set
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	64-bit World wide name
	   *	IDLE_IMMEDIATE with UNLOAD
	   *	WRITE_UNCORRECTABLE_EXT command
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Phy event counters
	   *	Idle-Unload when NCQ is active
	   *	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
	   *	SMART Command Transport (SCT) feature set
	   *	SCT Read/Write Long (AC1), obsolete
	   *	SCT Write Same (AC2)
	   *	SCT Error Recovery Control (AC3)
	   *	SCT Features Control (AC4)
	   *	SCT Data Tables (AC5)
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	174min for SECURITY ERASE UNIT. 174min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000039402700e3c
	NAA		: 5
	IEEE OUI	: 000039
	Unique ID	: 402700e3c
Checksum: correct
$

J'ai testé des valeurs de bs allant de 512 octets à 8 Mio, en montant par puissances de 2 : 512 B, 1 K, 2 K, 4 K, …, 2 M, 4 M, 8M (selon la notation de man dd : K=Kio, M=Mio).
J'ai copié 1 Gio à partir de /dev/zero dans un fichier de mon home, ce qui n'est peut-être pas pareil que d'écrire directement sur le disque entier ou une partition, comme j'avais fait la fois précédente.
En tout cas, je trouve plutôt 16 K comme valeur optimale pour bs cette fois-ci, même si ça ne change pas fondamentalement les ordres de grandeur.
Voici le graphe de ces tests :

Et tant qu'à faire, voici la commande utilisée pour faire ces tests :

cp_size=$((1024*1024*1024))
for ((i=0;i<=14;i++)); do
  bs=$((512*(2**i)))
  count=$((cp_size/bs))
  echo "bs = $bs"
  dd if=/dev/zero of=/home/user/f bs=$bs count=$count
  echo
done

Caribou22 · Le 15/10/2019, à 19:45

Bonjour

Je profite de ce fil pou poser une question : est-ce que l'option "écraser les données existantes avec des zéros (lent)" du logiciel Gnome-disk-utility fait la même chose que cette commande ?

sudo dd if=/dev/zero of=/dev/sdX

@rmy : merci à toi de m'avoir bien dépanné en 2014 !
Si tu récupères des disques durs HS, j'en ai quelques uns à débarrasser. Comment tu les recycles ?

Désolé pour ce petit hors-sujet.

rmy · Le 15/10/2019, à 19:57

kamaris a écrit :

TOSHIBA MK6476GSX (640 GB)
174min for SECURITY ERASE UNIT.
En tout cas, je trouve plutôt 16 K comme valeur optimale pour bs cette fois-ci, même si ça ne change pas fondamentalement les ordres de grandeur.

60Mo/s (ou Mio/s ?) c'est effectivement la valeur optimale pour ce disque.

rmy · Le 15/10/2019, à 20:01

Caribou22 a écrit :

Bonjour
Je profite de ce fil pou poser une question : est-ce que l'option "écraser les données existantes avec des zéros (lent)" du logiciel Gnome-disk-utility fait la même chose que cette commande ?
sudo dd if=/dev/zero of=/dev/sdX
@rmy : merci à toi de m'avoir bien dépanné en 2014 !
Si tu récupères des disques durs HS, j'en ai quelques uns à débarrasser. Comment tu les recycles ?
Désolé pour ce petit hors-sujet.

Pour ta première question : oui
Pour ta deuxième question : ça dépend du niveau de sécurité souhaité et de l'état matériel de ceux-cis. Pour la grande majorité c'est du stockage en attente d'utilisation pour pièces, si il faut sécuriser je wipe (/dev/zero), et si l'état ne le permet pas je bousille les plateaux. Le recyclage direct, y'a que ça de vrai !

kamaris · Le 15/10/2019, à 20:23

rmy a écrit :

60Mo/s (ou Mio/s ?) c'est effectivement la valeur optimale pour ce disque.

Non dd sort bien des valeurs en Mo/s apparemment. Pour bs=16 K, j'ai

1073741824 octets (1,1 GB, 1,0 GiB) copiés, 17,3941 s, 61,7 MB/s

Le 61,7 MB/s et le 1,1 GB se correspondent bien quand on fait le calcul inverse.

rmy · Le 15/10/2019, à 20:35

kamaris a écrit :

rmy a écrit :
60Mo/s (ou Mio/s ?) c'est effectivement la valeur optimale pour ce disque.
Non dd sort bien des valeurs en Mo/s apparemment. Pour bs=16 K, j'ai
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 17,3941 s, 61,7 MB/s
Le 61,7 MB/s et le 1,1 GB se correspondent bien quand on fait le calcul inverse.

Alors ça colle complètement avec les 174min pour 640GB

Nuliel · Le 15/10/2019, à 20:41

Du coup ddrescue trouve tout seul la meilleure valeur pour le bs?
Sinon il y a une méthode conseillée pour la trouver cette valeur?

rmy · Le 15/10/2019, à 21:22

Naziel a écrit :

Du coup ddrescue trouve tout seul la meilleure valeur pour le bs?
Sinon il y a une méthode conseillée pour la trouver cette valeur?

Je n'ai pas la réponse ni à l'une ni à l'autre question.
Je constate que ddrescue a toujours le débit optimal sur un disque, sauf si tu fais plusieurs wipe en même temps, ou qu'il y a un autre facteur limitant que le disque lui-même.
Et pour la méthode j'y serais allé à tatons en me disant que de toutes façons ton disque a un cache, ton ordi gère aussi avec pour limite sa RAM, et que donc tant que tu n'imposes pas des écritures synchrones, ça va bien finir par sortir de l'entonoir…

Intuitivement comme sur les RAIDS les tailles de stripes sont en général entre 64K et 1M pour la plupart, je serais resté dans cet ordre de grandeur.

Dernière modification par rmy (Le 15/10/2019, à 21:23)

Nuliel · Le 15/10/2019, à 21:26

Ok, c'est noté

Pam547 · Le 16/10/2019, à 08:16

Bonjour,

Les tests de kamaris et les préconisations de son hdparm -I /dev/sda sont d'accord pour bs = 16 K

Chez moi avec un ssd :

Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 1	Current = 1
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns

R/W multiple sector transfer: Max = 1 Current = 1 Visiblement une technologie différente .

Nasman · Le 16/10/2019, à 08:35

Il y a aussi la possibilité de mettre

status=progress

après le sudo dd...
Ainsi tu verras l'état d'avancement. Il n'empêche que même avec un bs important, cette opération est longue.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 14/10/2019, à 14:15

Remise à zero disque dur par DD

#2 Le 14/10/2019, à 14:55

Re : Remise à zero disque dur par DD

#3 Le 14/10/2019, à 17:33

Re : Remise à zero disque dur par DD

#4 Le 14/10/2019, à 17:36

Re : Remise à zero disque dur par DD

#5 Le 14/10/2019, à 18:55

Re : Remise à zero disque dur par DD

#6 Le 14/10/2019, à 20:49

Re : Remise à zero disque dur par DD

#7 Le 15/10/2019, à 06:08

Re : Remise à zero disque dur par DD

#8 Le 15/10/2019, à 06:40

Re : Remise à zero disque dur par DD

#9 Le 15/10/2019, à 11:27

Re : Remise à zero disque dur par DD

#10 Le 15/10/2019, à 12:50

Re : Remise à zero disque dur par DD

#11 Le 15/10/2019, à 13:58

Re : Remise à zero disque dur par DD

#12 Le 15/10/2019, à 14:03

Re : Remise à zero disque dur par DD

#13 Le 15/10/2019, à 14:17

Re : Remise à zero disque dur par DD

#14 Le 15/10/2019, à 19:35

Re : Remise à zero disque dur par DD

#15 Le 15/10/2019, à 19:45

Re : Remise à zero disque dur par DD

#16 Le 15/10/2019, à 19:57

Re : Remise à zero disque dur par DD

#17 Le 15/10/2019, à 20:01

Re : Remise à zero disque dur par DD

#18 Le 15/10/2019, à 20:23

Re : Remise à zero disque dur par DD

#19 Le 15/10/2019, à 20:35

Re : Remise à zero disque dur par DD

#20 Le 15/10/2019, à 20:41

Re : Remise à zero disque dur par DD

#21 Le 15/10/2019, à 21:22

Re : Remise à zero disque dur par DD

#22 Le 15/10/2019, à 21:26

Re : Remise à zero disque dur par DD

#23 Le 16/10/2019, à 08:16

Re : Remise à zero disque dur par DD

#24 Le 16/10/2019, à 08:35

Re : Remise à zero disque dur par DD

Pied de page des forums