Paweł Goleń, blog

Od czego zależy szybkość czyszczenia dysku

Czas czyszczenia dysku będzie zależała od dwóch rzeczy:

• wydajności "generatora" danych użytych jako "dane nadpisujące",
• wydajności zapisu na dysk,

Wydajność generatora

W roli generatora można użyć na przykład:

• /dev/zero
• /dev/random
• /dev/urandom

Różnica między random i urandom zależy od konkretnego systemu, w OpenBSD /dev/random jest (...) reserved for future support of hardware random generators (...), za to jest (u|a|s)random. Przykłady pochodzą z BackTrack 4 uruchomionego w maszynie wirtualnej.

Wydajność generatora można sprawdzić w prosty sposób:

[email protected]:~# dd if=/dev/zero of=/dev/null
2240429+0 records in
2240428+0 records out
1147099136 bytes (1.1 GB) copied, 38.8762 s, 29.5 MB/s

[email protected]:~# dd if=/dev/zero of=/dev/null bs=4k
502083+0 records in
502082+0 records out
2056527872 bytes (2.1 GB) copied, 9.45589 s, 217 MB/s

[email protected]:~# dd if=/dev/zero of=/dev/null bs=16k
606301+0 records in
606300+0 records out
9933619200 bytes (9.9 GB) copied, 16.7945 s, 591 MB/s

[email protected]:~# dd if=/dev/zero of=/dev/null bs=32k
259528+0 records in
259528+0 records out
8504213504 bytes (8.5 GB) copied, 10.2575 s, 829 MB/s

Przy okazji zwracam uwagę na wartość parametru bs, wraz z którego wzrostem, rośnie wydajność.

Dla porównania wyniki dla /dev/random i /dev/urandom i bs 4k oraz 8k:

[email protected]:~# dd if=/dev/random of=/dev/null bs=4k
0+1 records in
0+1 records out
50 bytes (50 B) copied, 11.7998 s, 0.0 kB/s

[email protected]:~# dd if=/dev/random of=/dev/null bs=8k
0+2 records in
0+2 records out
25 bytes (25 B) copied, 18.1658 s, 0.0 kB/s

[email protected]:~# dd if=/dev/urandom of=/dev/null bs=4k
5843+0 records in
5842+0 records out
23928832 bytes (24 MB) copied, 12.8305 s, 1.9 MB/s

[email protected]:~# dd if=/dev/urandom of=/dev/null bs=8k
3620+0 records in
3619+0 records out
29646848 bytes (30 MB) copied, 15.9224 s, 1.9 MB/s

Niska wydajność /dev/random nie powinna dziwić. Urządzenie to ma dostarczać danych "dobrze" losowych, konieczne jest więc zbieranie entropii (...). Używanie /dev/random nie jest więc zbyt szczęśliwym pomysłem. Również i /dev/urandom nie spisuje się najlepiej. Wydajność rzędu 2 MB/s jest niższa, niż wydajność zapisu obecnych dysków twardych...

Wydajność zapisu

Wydajność zapisu można sprawdzić przy pomocy /dev/zero:

[email protected]:~# dd if=/dev/zero of=test.dat bs=512
43119+0 records in
43119+0 records out
22076928 bytes (22 MB) copied, 5.23621 s, 4.2 MB/s

[email protected]:~# dd if=/dev/zero of=test.dat bs=4k
33088+0 records in
33088+0 records out
135528448 bytes (136 MB) copied, 8.20089 s, 16.5 MB/s

[email protected]:~# dd if=/dev/zero of=test.dat bs=8k
32253+0 records in
32253+0 records out
264216576 bytes (264 MB) copied, 14.344 s, 18.4 MB/s

[email protected]:~# dd if=/dev/zero of=test.dat bs=16k
10065+0 records in
10065+0 records out
164904960 bytes (165 MB) copied, 8.63379 s, 19.1 MB/s

[email protected]:~# dd if=/dev/zero of=test.dat bs=32k
6362+0 records in
6362+0 records out
208470016 bytes (208 MB) copied, 10.7379 s, 19.4 MB/s

Jak widać przy bs rzędu 16k czy 32k osiągana prędkość zapisu to w tym przypadku około 19 MB/s. Dziesięć razy więcej(!) niż to, co udało się osiągnąć z /dev/urandom. Tak, wiem, że te wyniki mogą być nieco "poprawione" przez mechanizm cache, który pośredniczy przy zapisie na dysk. Teoretycznie tego usprawnienia można się pozbyć w ten sposób:

[email protected]:~# dd if=/dev/zero of=test.dat bs=32k oflag=direct
5486+0 records in
5486+0 records out
179765248 bytes (180 MB) copied, 13.2128 s, 13.6 MB/s

Widać wyraźny spadek wydajności, można jednak osiągnąć lepsze wyniki, metodą prób i błędów:

[email protected]:~# dd if=/dev/zero of=test.dat bs=1M oflag=direct
472+0 records in
472+0 records out
494927872 bytes (495 MB) copied, 19.6254 s, 25.2 MB/s

Porównując powyższy rezultat z "typowym" uruchomieniem dd bez optymalizacji (z wyjątkiem flagi direct) można doznać "drobnego" szoku:

[email protected]:~# dd if=/dev/zero of=test.dat oflag=direct
8049+0 records in
8049+0 records out
4121088 bytes (4.1 MB) copied, 7.49041 s, 550 kB/s

Z tych kilku prostych przykładów wynika jasno, że wydajność zapisu na dysk będzie w istotny sposób zależała nie tylko od wydajności dysku, ale i od parametrów uruchomienia dd. Uruchomienie go z domyślnymi parametrami nie jest szczęśliwym pomysłem, wydajność w tym przypadku będzie dramatyczna.

Jak czyścić dysk

Na podstawie powyższych wyników można stwierdzić, że w przypadku użycia dd do czyszczenia dysku należy:

• określić odpowiednie parametry dd w celu optymalizacji szybkości zapisu,
• jako "źródło" danych użyć /dev/zero a nie /dev/urandom,

Odnośnie tematu skutecznego usuwania danych z dysków funkcjonuje wiele nie do końca prawdziwych opinii. Jedną z nich jest możliwość odzyskiwania nadpisanych danych, nawet do kilku "warstw" w głąb. Opinia ta nie do końca jednak znajduje potwierdzenie: What happens when you overwrite data? Oznacza to, że w większości przypadków w zupełności wystarczające jest jednokrotne nadpisanie dysku. Nie odgrywa również większej roli to, czym dane są nadpisywane. W związku z tym jeśli dysk jest czyszczony przy pomocy dd wykorzystywanie /dev/urandom nie jest uzasadnione. No chyba, że w konkretnym przypadku jest w stanie generować dane wystarczająco szybko...

Lepiej użyć dedykowanych narzędzi

Do czyszczenia dysków warto użyć narzędzi, które są właśnie do tego przeznaczone, na przykład Darik's Boot And Nuke czy Secure Erase. Takie narzędzia mogą wyczyścić dysk lepiej niż dd. Nie dlatego, że użyją jakiegoś tajemnego wzorca zapisywanych danych, ale dlatego, że uwzględnią (a przynajmniej będą próbować) usunąć dane z niektórych obszarów dysków, które przez dd zostaną zapewne pominięte, na przykład z sektorów znajdujących się na g-list.