Dalam tutorial online sering disarankan untuk menggunakan perintah berikut untuk menyalin CDROM ke gambar iso:
$ dd if=/dev/dvd of=foobar.iso bs=2048
Mengapa ukuran byte harus ditentukan? Saya perhatikan bahwa sebenarnya 2048 adalah ukuran byte standar untuk gambar CDROM tetapi tampaknya ddtanpa menentukan bs=atau count=berfungsi juga.
Dalam keadaan apa akan bermasalah untuk tidak menentukan bs=atau count=kapan menyalin dari perangkat ukuran terbatas?
Jawaban:
Kapan dd cocok untuk menyalin data? (atau, ketika dibaca () dan tulis () parsial) menunjukkan peringatan penting saat menggunakan count: dddapat menyalin blok parsial, sehingga ketika diberikan countakan berhenti setelah jumlah blok yang diberikan, bahkan jika beberapa blok tidak lengkap. Karena itu Anda mungkin berakhir dengan lebih sedikit dari bs * countbyte yang disalin, kecuali jika Anda tentukan iflag=fullblock.
Ukuran blok default untuk dd adalah 512 byte. countadalah batas; sebagai pertanyaan Anda mengisyaratkan itu tidak diperlukan ketika menyalin perangkat ukuran terbatas, dan benar-benar dimaksudkan untuk menyalin hanya sebagian perangkat.
Saya pikir ada dua aspek yang perlu dipertimbangkan di sini: kinerja dan pemulihan data.
Sejauh menyangkut kinerja, Anda idealnya menginginkan ukuran blok setidaknya sama dengan, dan kelipatan, ukuran blok fisik yang mendasarinya (karenanya 2048 byte saat membaca CD-ROM). Bahkan saat ini Anda juga dapat menentukan ukuran blok yang lebih besar untuk memberikan sistem caching yang mendasarinya kesempatan untuk melakukan buffer untuk Anda. Tetapi meningkatkan ukuran blok berarti ddharus menggunakan lebih banyak memori, dan itu bisa menjadi kontra-produktif jika Anda menyalin melalui jaringan karena fragmentasi paket.
Sejauh menyangkut pemulihan data, Anda dapat mengambil lebih banyak data dari hard disk yang gagal jika Anda menggunakan ukuran blok yang lebih kecil; inilah yang dilakukan oleh program seperti dd-rescueitu secara otomatis: mereka membaca blok besar pada awalnya, tetapi jika blok gagal mereka membacanya kembali dengan ukuran blok yang lebih kecil. ddtidak akan melakukan ini, itu hanya akan gagal seluruh blok.
Ada sedikit pemujaan di sekitar dd. Awalnya, ada dua bug cpyang menyebabkan masalah: Ini akan salah mendeteks file sebagai jarang ketika dilaporkan dengan ukuran blok selain 512 (Linux menggunakan ukuran blok 1024), dan tidak menghapus blok kosong dari tujuan ketika menyalin dari file jarang ke perangkat blokir.
Anda dapat menemukan beberapa referensi untuk ini di arsip milis Linux awal .
Jadi orang terbiasa menjadi cara yang benar untuk menangani gambar disk, dan cp jatuh di pinggir jalan. Dan karena dd menggunakan ukuran blok default 512, itu lambat (lebih lambat dari cp pada sistem modern). Tetapi tidak jelas ukuran blok apa yang harus Anda gunakan. Mungkin dalam kasus Anda seseorang telah membaca bahwa 2048 adalah ukuran blok "alami" untuk CD-ROM (yaitu, CD-ROM dibagi menjadi 2.352 sektor byte yang berisi 2.048 byte data bersama dengan informasi koreksi kesalahan) dan telah memutuskan bahwa ini adalah ukuran "benar" untuk digunakan dengan dd, padahal sebenarnya Anda mungkin akan mendapatkan hasil yang lebih cepat jika Anda menggunakan ukuran blok yang lebih besar. Faktanya, GNU cp menggunakan ukuran blok default 64k untuk alasan ini.
tl; dr: cp /dev/dvd foobar.iso harusnya bekerja dengan baik. Ukuran blok default ddadalah 512. Satu-satunya efek meninggalkannya saja kemungkinan besar dalam sebagian besar keadaan modern adalah membuat proses penyalinan lebih lambat.
Mengubah ukuran blok adalah cara yang baik untuk mengubah berapa banyak buffered atau dibaca / ditulis sekaligus.
Tidak benar-benar berhubungan dengan apakah itu perangkat blok nyata atau yang tak terbatas / virtual. Ini tentang seberapa banyak Anda ingin disimpan dalam memori sebelum ddmenulisnya. bs=menetapkan keduanya ibs=(berapa banyak data yang dibaca sekaligus) dan obs=(berapa banyak data yang ditulis sekaligus). Semakin tinggi semakin obs=banyak iterasi ibs=akan diperlukan sebelum Anda memiliki cukup data untuk ddmulai menulis ke tujuan.
count=juga tidak bergantung pada apa pun selain apa yang ingin Anda lakukan. Ini mengontrol berapa banyak "blok" (yang diukur dengan ibs=) akan diperlukan untuk ddmempertimbangkan pekerjaannya yang sedang dilakukan.
ddmenyalin sebagian blok - tidak selalu bs * count.
ddtanpa bs=2048atau beberapa daripadanya akan memberikan kesalahan saat membaca dari drive blok perangkat cdrom.
Menggunakan opsi blocksize ddsecara efektif menentukan berapa banyak data yang akan disalin ke memori dari sub-sistem input I / O sebelum mencoba untuk menulis kembali ke sub-sistem I / O output. Outputnya sama (karena seluruh disk sedang disalin), potongan hanya dibaca pada ukuran yang berbeda yang Anda tentukan (sebagian besar ddimplementasi berjalan dengan ukuran blok default 512 byte).
Jika Anda memiliki memori cadangan dalam jumlah besar dan meningkatkan ukuran blok, maka potongan data yang lebih besar dapat dibaca secara berurutan, disangga, dan dibilas ke tujuan keluaran. Ukuran blok yang lebih rendah membutuhkan lebih banyak overhead dalam hal masing-masing individu, memset dll.
Jarak tempuh Anda mungkin berbeda-beda tergantung di mana Anda if=dan of=diatur, dan perangkat keras apa yang Anda lalui, jika Anda memiliki memori rendah dan sebagainya.
The bs = merupakan ukuran blok untuk membaca atau menulis. Meninggalkan bidang utuh atau tidak menentukannya mungkin tampak melakukan pekerjaan yang sama menyalin tetapi ada fakta tersembunyi dalam menggunakannya. Sebagai contoh,
Dalam kasus pertama menggunakan ukuran blok yang lebih rendah telah ditemukan untuk meningkatkan kecepatan penyalinan. Sementara di yang terakhir, ukuran blok yang lebih tinggi telah menjadi pilihan yang lebih baik karena ia meningkatkan ukuran sektor dan mengurangi jumlah sector changeperintah, yang biasanya menghasilkan operasi I / O yang lebih cepat.
dd bs=4m iflag=fullblockvsdd bs=1111dan perhatikan tingkat data yang jauh lebih tinggi yang diberikan mantan. Ini karena yang pertama sejajar dengan ukuran blok alami pada kartu SD, sedangkan yang terakhir membutuhkan pengontrol SD untuk melakukan banyak membaca, menyalin dan merenungkan untuk menulis blok fisik parsial. Pentingnyafullblocktidak boleh diremehkan, omong-omong, karena tanpa itu,bshanya pembacaan yang maksimal dan parsial dapat menyebabkan ketidakselarasan berikutnya yang persisten.