Bs parametresinin dd için optimal değerini belirlemenin bir yolu var mı?

Zaman zaman, çevrimiçi '' bs = 'olarak ayarladığınızdan emin olun, çünkü varsayılan değer çok uzun sürecek' 've kendi son derece bilimsel olmayan deneyimlerim' boyunca çevrimiçi yorumlar gördüm, bu diğerinden daha uzun sürdü geçen hafta saat "buna dayanıyor gibi görünüyor. Bu yüzden ne zaman 'dd' kullanmalıysam (genellikle 1-2GB aralığında) bytes parametresini belirlediğimden emin oluyorum. Yaklaşık yarısı, kopyaladığım çevrimiçi kılavuzda belirtilen değeri kullanıyorum; zamanın geri kalan kısmı 'fdisk -l' listesinden daha yavaş bir ortam olduğunu düşündüğüm için mantıklı olan bir sayı seçeceğim (örneğin yazdığım SD kart).

Belirli bir durum için (medya tipi, veri yolu boyutları veya diğer hususlar), "en iyi" bir değer belirlemenin bir yolu var mı? Belirlenmesi kolay mı? Değilse, yolun% 90-95'ini almanın kolay bir yolu var mı? Yoksa "sadece 512'den büyük bir şey seç" doğru cevabı bile mi?

Deneyi kendim denemeyi düşündüm, ancak (çok fazla çalışmaya ek olarak) cevabı hangi faktörlerin etkilediğinden emin değilim, bu yüzden iyi bir deneyi nasıl tasarlayacağımı bilmiyorum.

ddeski IBM anabilgisayar bantlarını çevirmek gerektiğinde arkadan tarihlenir ve blok boyutu, kaseti yazmak için kullanılanla eşleşmek zorunda kalır ya da veri blokları atlanır ya da kesilirdi. (9 kanallı bantlar titizdi. Uzun süre öldüklerine sevindik.) Bu günlerde, blok büyüklüğü cihaz sektörünün büyüklüğünün bir katı olmalıdır (genellikle 4KB, ancak çok yeni disklerde çok daha büyük ve çok küçük baş parmaklarda olabilir). sürücüler daha küçük olabilir, ancak 4KB ne olursa olsun makul bir temeldir) ve performans ne kadar büyükse o kadar iyidir. Sabit disklerde genellikle 1 MB'lık blok boyutları kullanırım. (Bu günlerde atmak için daha fazla hafızamız var.)

Optimum blok boyutunu belirlemenin tek yolu var ve bu bir kıyaslama. Sadece hızlı bir kıyaslama yaptım. Test makinesi, çekirdek 2.6.32 ve coreutils 8.5 ile Debian GNU / Linux çalıştıran bir bilgisayardır. Her iki dosya sistemi de sabit disk bölümündeki LVM birimlerinde ext3'dür. Kaynak dosya 2GB’tır (kesin olması gereken 2040000kB). Önbelleğe alma ve arabelleğe alma etkindir. Her koşmadan önce önbelleği boşalttım sync; echo 1 >|/proc/sys/vm/drop_caches. Çalışma süreleri synctamponları yıkamak için bir son içermez ; final sync1 saniyelik siparişi alır. Çalışmalar sameaynı dosya sistemine kopyalandı; diffishal, farklı bir sabit disk üzerinde bir dosya sistemine kopyalar idi. Tutarlılık için, bildirilen süreler,timeyarar, saniyeler içinde. Her bir komutu yalnızca bir kez koştum, bu yüzden zamanlamada ne kadar değişkenlik olduğunu bilmiyorum.

             same   diff
dd bs=64M    71.1   51.3
dd bs=1M     73.9   41.8
dd bs=4k     79.6   48.5
dd bs=512    85.3   48.9
cat          76.2   41.7
cp           77.8   45.3

Sonuç: Büyük bir blok boyutu (birkaç megabayt) yardımcı olur, ancak önemli ölçüde değil (aynı sürücü kopyalar için beklediğimden çok daha az). Ve catve cpçok kötü yapmazlar. Bu sayılarla dduğraşmaya değmez. Git hadi cat!

Geekosaur ile boyutun, 4K olan blok boyutunun bir katı olması gerektiğine katılıyorum.

Blok boyutunu bulmak istiyorsanız stat -c "%o" filenamemuhtemelen en kolay seçenektir.

Ama söylediğini yap dd bs=4K, demek istediğin read(4096); write(4096); read(4096); write(4096)...

Her sistem çağrısı, bir miktar ek yük içeren bir bağlam anahtarını içerir ve G / Ç programlayıcısına bağlı olarak, serpiştirilmiş yazma işlemleriyle okunan diskin çok sayıda arama yapmasına neden olabilir. (Muhtemelen Linux zamanlayıcı ile ilgili önemli bir sorun değil, yine de düşünülmesi gereken bir şey.)

Bu nedenle bs=8K, diski bir seferde iki blok okumasına izin verin, muhtemelen disk üzerinde birbirine yakın olan ve aynı zamanda yazma işlemini yapacak başka bir yer aramadan (veya başka bir işlem için G / Ç servisini yapmadan) önce disk üzerinde okumaya izin verirsiniz.

Bu mantıkla, bs=16Kdaha da iyi, vb.

Öyleyse bilmek istediğim, performansın kötüleşmeye başladığı bir üst sınır varsa ya da sadece hafıza ile sınırlandırılmışsa.

Gilles söylediği gibi sizin için en uygun parametreyi belirleyebilir bs seçeneği dd kıyaslama yoluyla. Bununla birlikte, şu soru soruluyor: Bu parametreyi nasıl uygun bir şekilde kıyaslayabilirsiniz?

Bu soruya geçici cevabım şudur: son zamanlarda tam olarak bu sorunu çözmek için üzerinde çalışmaya başladığım yardımcı program olan dd-opt'i kullanın :)

En iyi çalışıyor gibi görünüyor sdcard okuyucu usb2.0 için optimize edilmiş bs=10M. Ben 4k, 16M'ye kadar, 8-10M'den sonra gelişme olmadı. Aktarım hızı ölçümünün büyük olasılıkla cihazda tamponları yükledikten sonra ... cihazın asıl ortama aktarılmasını beklediğinden dolayı nasıl bozulduğunu görebilirsiniz.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s