jak długo wyzerować dysk z dd? [Zamknięte]

14

Jak długo zajmie zerowanie zapełnienia 1 TB (używając dd dev / zero)?

Właściwie robię dwa dyski 500G jednocześnie, jeśli to ważne.

— Miles Marley
źródło

3

Powiedz nam, ile czasu zajęło dd dysków z zerami?

— Rolnik

1

Mój dysk WD 1 TB (5400 obr./min) zajmuje około 240 minut, ale jest stary i ma przeniesione sektory. Nawiasem mówiąc, nie różni się tak bardzo od tego, jak sprytne raporty, jak czas oczekiwania na przedłużony autotest (255 minut)

— Barrymac

2

Dodanie kolejnego punktu danych: właśnie uruchomiłem dd if=/dev/zero of=/dev/sdX bs=8Mna dwóch zupełnie nowych dyskach Seagate ST4000DM000 4 TB jednocześnie przez porty SATA-300 (myślę, że można go mniej więcej idealnie równolegle - wykorzystanie procesora było stałe na poziomie ~ 20% dla pierwszego ddprocesu przed uruchomieniem drugiego , a następnie oba zajęły ~ 20%). Pierwszy dysk zakończył się w 8h50min (530 min), a drugi w 8h30min (510 min). Sprowadza się to do prędkości zapisu ~ 130 MB / s na dysk, co nie jest takie dziwne, biorąc pod uwagę wejście monotoniczne. Sprzęt pochodzi z 2009 roku (procesor: C2D E8400; chipset: Intel P43 / ICH10).

— Daniel Andersson,

9

Zależy to od wielu czynników, w tym między innymi:

Prędkość dysku (RPM)
Wbudowana pamięć podręczna dysku
Liczba talerzy i informacja, czy można zapisać jednocześnie na wielu talerzach
Interfejs dysku (SATA / SCSI itp.)
Wydajność kontrolera interfejsu
Konfiguracja napędów (np. Osobne kanały lub ten sam kanał)

Ponadto, chociaż zerowanie dysku jest prostym zadaniem dla procesora i pamięci RAM, nadal może wystąpić efekt:

Wydajność procesora
Dostępna pamięć RAM
Szybkość pamięci RAM
Inne zadania wykonywane są w tym samym czasie
Ustawienia zarządzania energią

Zakładając, że całkiem nowy komputer z dyskami średniej klasy, na minimalnym dysku rozruchowym z linuksem, WYŁĄCZNIE operacja zerowania (bez GUI, Internetu itp.) Załadowana całkowicie do pamięci RAM, może trwać od 2 do 12 godzin. Gdybym musiał wyrzucić jeden numer, powiedziałbym, że bliżej 3 i pół godziny, ale znowu, nie ma wystarczających informacji, aby uzyskać dobre oszacowanie poza faktycznym wykonaniem tego.

Jeśli masz więcej niż 1 GB wolnego miejsca, możesz spróbować zamontować dysk i uruchomić dd if=/dev/zero bs=512 count=2048 of=/tmp/tempzeroinny plik. Jeśli wiesz więcej na temat optymalnego rozmiaru bloku dla najszybszego zapisu na dysk, możesz użyć tego dla wartości bs (w kilobajtach) i ustawić licznik na dowolną wielkość pliku. Następnie możesz użyć tego, aby uzyskać lepsze oszacowanie bez utraty danych. Po prostu utworzy duży plik zawierający zera.

— TuxRug
źródło

3

Z mojego doświadczenia na dyskach twardych z ostatniej dekady, bs = 1M to ogromna poprawa w stosunku do bs = 512 i jest wystarczająco dobra, aby używać jej domyślnie, nie martwiąc się zbytnio o znalezienie optymalnego.

— crazyscot,

@crazyscot tak ogromna różnica tam z bs = 1M, aby zastąpić straszne domyślne ustawienie bs = 512. Również ddrescue (sprawdź, jak ustawić w nim rozmiar bloku), daje pasek procentowy / pasek postępu.

— barlop

2

Zrobiłem dd z losowymi danymi na dysku 750 GB. Myślę, że zajęło to około 20 godzin. Rzeczą, która tak naprawdę jest do kitu, jest to, że musiałem to zrobić cztery razy dla czterodyskowej macierzy RAID. Myślę, że wąskim gardłem jest prędkość zapisu twoich dysków. Jesteś mądry, robiąc to równolegle z napędami.

— Rolnik
źródło

2

Duża część problemu z wydajnością polegała prawdopodobnie na tym, że używasz liczb losowych. / dev / urandom lub jakiekolwiek inne źródło będzie bardzo starało się wygenerować naprawdę losowe liczby, zmniejszając w ten sposób przepustowość. Coś takiego jak / dev / zero nie będzie miało tego problemu.

— Sam Bisbee,

Czy istnieje ryzyko, że 1 TB zer zostanie skompresowany gdzieś w potoku w dół do pamięci i zniekształci wyniki? Nie mam na myśli skompresowania na dysku, ale jest przesyłany jako optymalizacja

— pufferfish

2

Z partycją +100 GB, Acer Aspire 5750G, zewnętrzny dysk twardy SATA, USB 2, 5400 obr./min:

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

i

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
źródło

1

Zgaduję, ale domyślam się, że będzie to zależeć od kontrolera napędu, kontrolera na płycie głównej i tego, co jeszcze pochłania CPU / IO.

Zgaduję, według godziny lub godzin. Dni wydają się długie. W zależności od konfiguracji komputera, jednoczesne uruchomienie obu może spowolnić proces tworzenia rywalizacji o kontroler napędu. Chociaż wypompowujesz zera, nic na twoim dysku nie wie o tym i musi zapisywać każdy bajt.

— Rich Homolka
źródło

1

Jeśli po prostu kasujesz dyski, doskonałym narzędziem do równoległej przepustowości jest DBAN w trybie prostego kasowania. Jest dostępny jako ISO i w zasadzie wykonuje dd if=/dev/zeropolecenia dla wybranych dysków.

— wajeemba
źródło

0

Powinno to zająć 2-5 godzin. Wąskim gardłem jest dysk, a nie pamięć RAM, procesor, kable lub konfiguracja kontrolera. Jeśli nie masz bardzo starego komputera, takiego jak oryginalny Pentium, procesor i pamięć są znacznie szybsze niż prędkość wrzeciona dysku twardego, podobnie jak kable SATA. Pamięć podręczna nawet nie wchodzi w grę, ponieważ zerujesz dysk (chyba że masz 1 TB pamięci podręcznej).

— Jordania
źródło