Czy lepiej jest użyć cat, dd, pv lub innej procedury do skopiowania płyty CD / DVD?

tło

Kopiuję niektóre dyski CD / DVD z danymi do plików ISO, aby użyć ich później bez potrzeby korzystania z nich w napędzie.

Szukam procedur w sieci i znalazłem wiele:

• Wykorzystanie catdo skopiowania nośnika: http://www.yolinux.com/TUTORIALS/LinuxTutorialCDBurn.html

  cat /dev/sr0 > image.iso
  

• Wykorzystanie ddtego (najwyraźniej najczęściej stosowane): http://www.linuxjournal.com/content/archiving-cds-iso-commandline

  dd if=/dev/cdrom bs=blocksize count=count of=/path/to/isoimage.iso
  

• Użyj po prostu, pvaby to osiągnąć: Zobacz, man pvaby uzyskać więcej informacji, chociaż oto ich fragment:

  Taking an image of a disk, skipping errors:
        pv -EE /dev/sda > disk-image.img
  
  Writing an image back to a disk:
        pv disk-image.img > /dev/sda
  
  Zeroing a disk:
        pv < /dev/zero > /dev/sda
  

Nie wiem, czy wszystkie z nich powinny być równoważne, chociaż niektóre z nich testowane (za pomocą md5sumnarzędzia), a co najmniej, ddi pvto nie równoważne. Oto md5sumzarówno dysk, jak i wygenerowane pliki przy użyciu każdej procedury:

md5 z procedury dd: 71b676875b0194495060b38f35237c3c

md5 procedury pv: f3524d81fdeeef962b01e1d86e6acc04

EDYCJA: To wyjście pochodziło z innej płyty CD niż dane wyjście. W rzeczywistości zdałem sobie sprawę, że istnieje kilka interesujących faktów, które podam jako odpowiedź.

W rzeczywistości rozmiar każdego pliku jest inny w porównaniu do siebie.

Czy istnieje najlepsza procedura kopiowania dysku CD / DVD, czy po prostu używam niepoprawnie poleceń?

Więcej informacji o sytuacji

Oto więcej informacji o przypadku testowym, którego używam do sprawdzenia procedur, które znalazłem do tej pory:

isoinfo -d i /dev/sr0 Dane wyjściowe: https://gist.github.com/JBFWP286/7f50f069dc5d1593ba62#file-isoinfo-output-19-aug-2015

ddaby skopiować nośnik, z wyjściowymi sumami kontrolnymi i informacjami o pliku Dane wyjściowe: https://gist.github.com/JBFWP286/75decda0a67605590d32#file-dd-output-with-md5-and-sha256-19-aug-2015

pvaby skopiować nośnik, z sumami wyjściowymi i informacjami o pliku Dane wyjściowe: https://gist.github.com/JBFWP286/700a13fe0a2f06ce5e7a#file-pv-output-with-md5-and-sha256-19-aug-2015

Każda pomoc będzie mile widziana!

Wszystkie poniższe polecenia są równoważne. Czytają bajty CD /dev/sr0i zapisują je w pliku o nazwie image.iso.

cat /dev/sr0 >image.iso
cat </dev/sr0 >image.iso
tee </dev/sr0 >image.iso
dd </dev/sr0 >image.iso
dd if=/dev/cdrom of=image.iso
pv </dev/sr0 >image.iso
cp /dev/sr0 image.iso
tail -c +1 /dev/sr0 >image.iso

Dlaczego miałbyś używać jednego nad drugim?

• Prostota. Na przykład, jeśli już znasz catlub cpnie musisz uczyć się kolejnego polecenia.

• Krzepkość. Ten jest trochę wariantem prostoty. Jakie jest ryzyko, że zmiana polecenia zmieni to, co robi? Zobaczmy kilka przykładów:

  • Wszystko z przekierowaniem: możesz przypadkowo umieścić przekierowanie w niewłaściwy sposób lub zapomnieć o nim. Ponieważ miejscem docelowym ma być nieistniejący plik, set -o noclobberupewnij się, że niczego nie nadpisujesz; jednak możesz nadpisać urządzenie, jeśli przypadkowo napiszesz >/dev/sda(na płycie CD, która jest tylko do odczytu, nie ma oczywiście ryzyka). To przemawia za cat /dev/sr0 >image.iso(trudnym do popełnienia błędu w szkodliwy sposób) nad alternatywami, takimi jak tee </dev/sr0 >image.iso(jeśli odwrócisz przekierowania lub zapomnisz wejściowe, teenapiszę /dev/sr0).
  • cat: możesz przypadkowo połączyć dwa pliki. Dzięki temu dane można łatwo odzyskać.
  • dd: ii osą blisko klawiatury i nieco niezwykłe. Nie ma odpowiednika noclobber, of=z radością nadpisze cokolwiek. Składnia przekierowań jest mniej podatna na błędy.
  • cp: jeśli przypadkowo podmienisz źródło i cel, urządzenie zostanie zastąpione (ponownie, zakładając, że urządzenie nie jest tylko do odczytu). Jeśli cpzostanie wywołany z niektórymi opcjami, takimi jak -Rlub -aktóre niektóre osoby dodają za pośrednictwem aliasu, skopiuje węzeł urządzenia, a nie zawartość urządzenia.

• Dodatkowa funkcjonalność. Jedynym narzędziem, które ma użyteczną dodatkową funkcjonalność, jest pvjego potężne opcje raportowania.
  Ale tutaj możesz sprawdzić, ile zostało skopiowanych, i tak patrząc na rozmiar pliku wyjściowego.

• Występ. Jest to proces związany z We / Wy; główny wpływ na wydajność ma rozmiar bufora: narzędzie odczytuje fragment ze źródła, zapisuje fragment do miejsca docelowego, powtarza. Jeśli porcja jest zbyt mała, komputer spędza czas na przełączaniu się między zadaniami. Jeśli porcja jest zbyt duża, operacji odczytu i zapisu nie można zrównoleglać. Optymalny rozmiar porcji na komputerze to zwykle około kilku megabajtów, ale jest to oczywiście bardzo zależne od systemu operacyjnego, sprzętu i tego, co jeszcze robi komputer. Jakiś czas temu przeprowadziłem testy porównawcze kopii dysku twardego na dysk twardy, w Linuksie, co pokazało, że w przypadku kopii na tym samym dysku, dd z dużym rozmiarem bufora ma tę zaletę, ale w przypadku kopii na wielu dyskach, catprzewyższało dowolny ddrozmiar bufora.

Jest kilka powodów, dla których ddtak często się o tym wspominasz. Oprócz wydajności nie są to szczególnie dobre powody.

• W bardzo starych systemach uniksowych niektóre narzędzia do przetwarzania tekstu nie radziły sobie z danymi binarnymi (używały wewnętrznie zakończonych znakiem zerowym ciągów , więc zwykle miały problemy z bajtami zerowymi; niektóre narzędzia zakładały również, że znaki używały tylko 7 bitów i nie poprawnie przetwarza 8-bitowe zestawy znaków). Nie jestem pewien, czy kiedykolwiek był problem z cat(było więcej narzędzi wiersza zorientowanych, takich jak head, seditp), ale ludzie raczej unikać jej na danych binarnych ze względu na jej związek z przetwarzaniem tekstu. Nie stanowi to problemu w nowoczesnych systemach, takich jak Linux, OSX, * BSD lub cokolwiek zgodnego z POSIX.
• Istnieje pewien mit, który ddjest nieco „niższy poziom” niż inne narzędzia, takie jak catbezpośredni dostęp do urządzeń. Jest to całkowicie fałszywe: dda także cati teewszyscy inni czytają bajty z ich danych wejściowych i zapisują bajty na swoich danych wyjściowych. Prawdziwa magia jest w środku /dev/sr0.
• ddma nietypową składnię wiersza poleceń, więc wyjaśnienie, jak to działa, daje więcej okazji, aby zabłysnąć, wyjaśniając coś, co tylko pisze cat /dev/sr0.
• Używanie dd z dużym rozmiarem bufora może mieć lepszą wydajność, ale nie zawsze tak jest (patrz niektóre testy porównawcze w systemie Linux ).

Głównym ryzykiem ddjest to, że może dyskretnie pomijać niektóre dane . Myślę, że ddjest bezpieczny, dopóki skipalbo countnie są przekazywane, ale nie jestem pewien, czy jest to przypadek na wszystkich platformach. Ale nie ma żadnej przewagi poza wydajnością.

Więc użyj, pvjeśli chcesz jego fantazyjny raport postępu, lub catjeśli nie.

W tym przypadku są interesujące fakty, szczególnie te:

• Właśnie sprawdziłem otrzymane dane wyjściowe (tym razem użyłem innej płyty, dokładnie płyty instalacyjnej Xubuntu 15.04 x64) i przy obu procedurach ( ddi pv) sumy kontrolne są identyczne .
• Miałem pomysł, aby po wykonaniu ddprocedury otworzyć napęd i zamknąć go za pomocą tego samego dysku, a następnie zakończyć test za pomocą pvprocedury. Robiąc to, otrzymałem identyczne kopie z obu procedur.
• I pomyśleć Mam różnych sum kontrolnych po raz pierwszy, bo z jakiegoś powodu, zebrane dane z napędu CD / DVD wydaje się być „nagrany” do innych celów przez pewien czas (np cache) - w ten sposób, inne operacje, takie jak sumy kontrolne były znacznie szybciej niż transfer. Proszę o komentarz, jeśli znasz dokładną przyczynę tego.
• Kolejnym faktem jest to, że ddw / o count=Xparametr przestaje poprawnie na końcu płyty i daje taki sam obraz jak Disc-z pv(sumy kontrolne są identyczne), więc lepiej dla mnie, aby korzystać ddw / o parametrach lub po prostu pv.

Na razie wydaje się pvi ddmożna wykonać kopię CD / DVD z takimi samymi wynikami.