quanto tempo azzerare un'unità con dd? [chiuso]

14

Quanto tempo ci vorrà per azzerare 1 TB (usando dd dev / zero)?

In realtà sto facendo due unità da 500 G contemporaneamente se è importante.

— Miles Marley
fonte

3

Quindi, dicci, quanto tempo ci è voluto per dd le unità con zeri?

— Rolnik,

1

La mia sata WD 1Tb (5400rpm) impiega circa 240 minuti, ma è vecchia e ha riallocato i settori. Per inciso, non è così diverso nello stesso momento in cui smart riporta il tempo previsto per un autotest prolungato (255 minuti)

— barrymac

2

Aggiunta di un altro punto dati: appena eseguito dd if=/dev/zero of=/dev/sdX bs=8Msu due nuovissime unità Seagate ST4000DM000 da 4 TB su porte SATA-300 contemporaneamente (penso che fosse più o meno perfettamente parallelizzabile - l'utilizzo della CPU era costante al ~ 20% per il primo ddprocesso prima dell'inizio del secondo , e poi entrambi hanno preso circa il 20% ciascuno). Il primo disco è terminato in 8h50min (530 min) e il secondo in 8h30min (510 min). Ciò equivale a una velocità di scrittura di ~ 130 MB / s per unità, il che non è poi così strano considerando l'ingresso monotono. L'hardware era del 2009 (CPU: C2D E8400; chipset: Intel P43 / ICH10).

— Daniel Andersson,

9

Dipende da molti fattori, inclusi ma non limitati a:

Velocità del disco (RPM)
Cache integrata nel disco
Numero di piatti e se è possibile scrivere su più piatti contemporaneamente
Interfaccia disco (SATA / SCSI, ecc.)
Prestazioni del controller di interfaccia
Configurazione degli azionamenti (es. Canali separati o stesso canale)

Inoltre, sebbene l'azzeramento di un'unità sia un compito semplice per CPU e RAM, potrebbe esserci ancora un effetto da:

Prestazioni della CPU
RAM disponibile
Velocità della RAM
Altre attività vengono eseguite contemporaneamente
Impostazioni di gestione dell'alimentazione

Supponendo che un computer abbastanza recente con unità di livello medio, su un disco di avvio minimo di Linux che esegua SOLO l'operazione di azzeramento (no gui, internet, ecc.) Caricato interamente nella RAM, potrebbe durare dalle 2 alle 12 ore. Se dovessi lanciare un singolo numero, direi più vicino alle 3 ore e mezza, ma ancora una volta, non ci sono abbastanza informazioni per ottenere una buona stima oltre a farlo effettivamente.

Se si dispone di più di 1 GB di spazio libero, è possibile provare a montare l'unità e eseguire dd if=/dev/zero bs=512 count=2048 of=/tmp/tempzeroo qualche altro file. Se sai di più sulla dimensione ottimale del blocco per una scrittura più veloce sul tuo disco, puoi usarlo per il valore bs (in kilobyte) e impostare il conteggio su qualunque cosa ti dia la dimensione del file che desideri. Quindi puoi usarlo per ottenere una stima migliore senza perdere dati. Creerà solo un file di grandi dimensioni che contiene zeri.

— TuxRug
fonte

3

Nella mia esperienza sui dischi rigidi dell'ultimo decennio o giù di lì, bs = 1M è un grande miglioramento rispetto a bs = 512 ed è abbastanza buono da usare come predefinito senza preoccuparsi troppo di trovare l'ottimale.

— crazyscot,

@crazyscot sì enorme differenza lì con bs = 1M per sovrascrivere il terribile default di bs = 512. Inoltre ddrescue (controlla come impostare la dimensione del blocco in esso), fornisce una barra percentuale / avanzamento.

— barlop

2

Ho fatto un dd con dati casuali su un disco da 750 GB. Penso che ci siano volute circa 20 ore. La cosa che mi ha fatto davvero schifo è che dovevo farlo quattro volte per un array RAID a quattro dischi. Penso che il collo di bottiglia sia la velocità di scrittura delle tue unità. Sei intelligente per farlo in parallelo alle unità.

— Rolnik
fonte

2

Gran parte del tuo problema di prestazioni era probabilmente l'utilizzo di numeri casuali. / dev / urandom o qualsiasi altra fonte cercherà molto di generare numeri veramente casuali, riducendo così il rendimento. Qualcosa come / dev / zero non avrà questo problema.

— Sam Bisbee,

Esiste il rischio che 1 TB di zeri venga compresso da qualche parte nella pipeline fino all'archiviazione e distorca i risultati? Non intendo realmente compresso sul disco, ma in transito come ottimizzazione

— pesce palla

2

Con una partizione di +100 GB, Acer Aspire 5750G, sata hdd esterno, usb 2, 5400rpm:

xxxx@acer-ubuntu:~$ sudo dd if=/dev/zero of=/dev/sdb2 bs=8M
[sudo] password for xxxx: 
dd: writing `/dev/sdb2': No space left on device
12500+0 records in
12499+0 records out
104856551424 bytes (105 GB) copied, 2846.87 s, 36.8 MB/s

e

xxxx@acer-ubuntu:~$ sudo dd if=/dev/zero of=/dev/sdb1 bs=8M
[sudo] password for xxxx: 
dd: writing `/dev/sdb1': No space left on device
6579+0 records in
6578+0 records out
55183409152 bytes (55 GB) copied, 1497.23 s, 36.9 MB/s

— hsmit
fonte

1

Sto indovinando, ma la mia ipotesi è che dipenderebbe dal controller dell'unità, dal controller sulla scheda madre e da cos'altro sta assorbendo CPU / IO.

Suppongo, nell'ordine delle ore o ore. I giorni sembrano lunghi. A seconda della configurazione della macchina, l'esecuzione di entrambi contemporaneamente può effettivamente rallentare le cose se si crea contesa per il controller dell'unità. Anche se stai pompando zeri, nulla nel tuo disco lo sa e deve scrivere ogni byte.

— Rich Homolka
fonte

1

Se stai solo cancellando le unità, un ottimo strumento da utilizzare per la velocità di trasmissione parallela è DBAN in modalità di cancellazione semplice. È disponibile come ISO e fondamentalmente esegue il dd if=/dev/zerocomando per te sulle unità selezionate.

— wajeemba
fonte

0

Dovrebbero essere necessarie 2-5 ore. Il collo di bottiglia è il disco, non la RAM, la CPU, i cavi o la configurazione del controller. A meno che tu non abbia un computer molto vecchio, come un Pentium originale, la tua CPU e memoria sono molto più veloci della velocità del mandrino del disco rigido, così come i tuoi cavi SATA. La cache non entra nemmeno in gioco perché stai azzerando l'unità (a meno che tu non abbia 1 TB di cache).

— Giordania
fonte