Nowe posty

Autor Wątek: disk dump  (Przeczytany 3524 razy)

zielas

  • Gość
disk dump
« dnia: 2008-09-18, 17:16:03 »
Witam

wymyśliłem sobie, aby zrobić zrzut całego dysku z laptopa z windows do jednego pliku z kompresją, urządzenie docelowe to dysk usb 1 TG;

do tego celu chcę użyć Knoppixa 5.0.1 i narzędzia disk dump i polecenia

dd if=/dev/hda bs=1024 | gzip > /mnt/sda1/BACKUP/laptop_2008-07-29.zip

dysk docelowy zapoełniony na 28 GB, plik wynikowy po 4 godzinach mielenia 26 GB i jeszcze mieli

mam pytanko, czy dobrze stosuję składnię? czy takie polecenie kompresuje w locie? a może będzie kompresować na koniec?
Czemu to tak długo trwa, jak przegranie tych plików ręcznie trwało dużo mniej

pozdrawiam

arctgx

  • Gość
disk dump
« Odpowiedź #1 dnia: 2008-09-18, 18:20:09 »
Podobno (nie mierzyłem czasu) wyzerowanie wolnej przestrzeni przed kompresją przyspiesza ją:
cat /dev/zero >plik; sync; rm -f plik
gdzie plik ma być stworzony w katalogu z zamontowaną partycją dysku hda (dla każdej z osobna). Uwaga: wybierz nieistniejącą nazwę pliku, bo w przeciwnym razie nieodwracalnie zniszczysz sobie istniejący.

Pomiar czasu wykonania robimy poprzedzając polecenie powłokowym słowem time.

Jeśli sda1 to partycja na pamięci USB, zapis na niej może być jeszcze jednym wąskim gardłem prócz kompresji.

WizardNumberNext

  • Gość
disk dump
« Odpowiedź #2 dnia: 2008-09-19, 09:36:49 »
Cytat: "arctgx"
Jeśli sda1 to partycja na pamięci USB, zapis na niej może być jeszcze jednym wąskim gardłem prócz kompresji.
Bez przesady, ale gzip nie jest zbyt szybki, a przynajmniej nie aż tak.
Cytat: "arctgx"
Podobno (nie mierzyłem czasu) wyzerowanie wolnej przestrzeni przed kompresją przyspiesza ją:
A i owszem to fakt - skoro działamy w trybie raw (a tak działamy) to czytamy również te miejsca, gdzie według systemu plików nic nie ma - czytam całą partycję bit po bicie.

arctgx

  • Gość
disk dump
« Odpowiedź #3 dnia: 2008-09-19, 14:33:09 »
Moglibyśmy spierać się o nieprecyzyjne pojęcia typu "szybki" lub "wąskie gardło", ale lepiej na konkretnym kontrolerze USB i sterowniku (*hci) i konkretnej pamięci i wybranym sposobie synchronizacji zrobić pomiar czasu zapisu.

Przy okazji odgrzebałem bardzo stary wątek z pewnym pomiarem:
http://forum.linux.pl/viewtopic.php?id=6532

micu

  • Gość
disk dump
« Odpowiedź #4 dnia: 2008-09-19, 18:01:43 »
Cześć!

Proponuję jeszcze sprawdzić czy nie będzie szybciej z innymi wielkościami "blocksize". Spróbuj na przykład bs=32k. W przypadku długotrwałego kopiowania może to zaoszczędzić trochę czasu.

Jak to określić ?  Jako że odczyt z urządzenia blokowego jest domyślne buforowany, kolejne wywołania "dd" będą szybsze i zafałszują wyniki. Dlatego testy należy przeprowadzać z opcją "iflag=direct" . Pamiętaj również, że w Twoim przypadku wynik jest przesyłany przez potok którego bufor ma maksymalnie 64k więc większe wartości raczej nie pomogą.

Poniżej wklejam co uzyskałem u siebie (256 MB z dysku SCSI na /dev/null w trybie direct I/O czyli ignorując bufory). Jak widać warto poeksperymentować.

Standardowo - 512 bajtów:
time dd iflag=direct if=/dev/sda of=/dev/null bs=512 count=524288 
524288+0 records in
524288+0 records out
268435456 bytes (268 MB) copied, 55.2004 s, 4.9 MB/s

real 0m55.204s
user 0m0.414s
sys 0m9.078s
1kB - z Twojego przykładu :
time dd iflag=direct if=/dev/sda of=/dev/null bs=1024 count=262144
262144+0 records in
262144+0 records out
268435456 bytes (268 MB) copied, 29.041 s, 9.2 MB/s

real 0m29.045s
user 0m0.252s
sys 0m4.839s
Jest duuużo lepiej - blok 32kB:
time dd iflag=direct if=/dev/sda of=/dev/null bs=32k count=8192 
8192+0 records in
8192+0 records out
268435456 bytes (268 MB) copied, 4.8555 s, 55.3 MB/s

real 0m4.859s
user 0m0.005s
sys 0m0.197s
I dla porównania - 64kB czyli dużo lepiej już nie będzie:
time dd iflag=direct if=/dev/sda of=/dev/null bs=64k count=4096
4096+0 records in
4096+0 records out
268435456 bytes (268 MB) copied, 4.88619 s, 54.9 MB/s

real 0m4.890s
user 0m0.004s
sys 0m0.118s
Pozdrawiam
Micu