it-swarm-eu.dev

Existuje způsob, jak určit optimální hodnotu parametru bs na dd?

Příležitostně jsem viděl komentáře online v řádcích „ujistěte se, že jste nastavili 'bs =', protože výchozí hodnota bude trvat příliš dlouho,“ a moje vlastní nesmírně nevědecké zkušenosti, „dobře, které se zdály trvat déle než ostatní čas minulý týden “to zřejmě vydrží. Takže pokaždé, když použiji 'dd' (obvykle v rozsahu 1-2 GB), ujistěte se, že zadám parametr bajtů. Asi polovinu času používám hodnotu uvedenou v libovolném online průvodci, ze kterého kopíruji; zbytek času si ze seznamu 'fdisk -l' vyberu nějaké číslo, které považuji za pomalejší médium (např. SD kartu, na kterou píšu).

Existuje pro danou situaci (typ média, velikosti sběrnice nebo cokoli jiného důležitého) způsob, jak určit „nejlepší“ hodnotu? Je snadné to určit? Pokud ne, existuje snadný způsob, jak se tam dostat 90-95% cesty? Nebo je „jen vybrat něco většího než 512“ i správná odpověď?

Přemýšlel jsem o pokusu sám, ale (kromě toho, že jsem hodně práce) si nejsem jistý, jaké faktory ovlivňují odpověď, takže nevím, jak navrhnout dobrý experiment.

74
user4443

dd data zezadu, kdy bylo potřeba překládat staré pásky IBM mainframe, a velikost bloku se musela shodovat s tou, která byla použita pro zápis pásky, nebo by se datové bloky přeskočily nebo zkrátily. (9 pásové pásky byly vybíravé. Buďte rádi, že jsou dlouho mrtví.) V těchto dnech by velikost bloku měla být násobkem velikosti sektoru zařízení (obvykle 4 kB, ale na nedávných discích může být mnohem větší a na velmi malém palci disky mohou být menší, ale 4KB je rozumná střední zem bez ohledu na to) a čím větší, tím lepší výkon. U pevných disků často používám velikosti bloků 1 MB. (V dnešní době máme mnohem víc paměti, abychom se mohli hádat.)

29
geekosaur

Existuje jen jeden způsob, jak určit optimální velikost bloku, a to je měřítko. Právě jsem udělal rychlý test. Testovacím počítačem je počítač, na kterém běží Debian GNU/Linux, s jádrem 2.6.32 a coreutils 8.5. Oba zapojené souborové systémy jsou ext3 na svazcích LVM na oddílu pevného disku. Zdrojový soubor je 2 GB (přesněji 2040000 kB). Ukládání do mezipaměti a ukládání do vyrovnávací paměti jsou povoleny. Před každým spuštěním jsem vyprázdnil mezipaměť pomocí sync; echo 1 >|/proc/sys/vm/drop_caches. Doby běhu nezahrnují finální sync pro vyprázdnění vyrovnávacích pamětí; poslední sync trvá řádově 1 sekundu.

Běhy same byly kopie ve stejném souborovém systému; běhy diff byly kopie do souborového systému na jiném pevném disku. Z důvodu konzistence jsou hlášené časy nástěnné hodiny získané pomocí nástroje time v sekundách. Každý příkaz jsem spustil pouze jednou, takže nevím, jak velké rozdíly jsou v načasování.

             same   diff
             t (s)  t (s)
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

Závěr: Velká velikost bloku (několik megabajtů) pomáhá, ale ne dramaticky (mnohem méně, než jsem očekával u kopií stejného disku). A cat a cp nefungují tak špatně. S těmito čísly se mi nelíbí dd, které by stálo za to. Jděte s cat!

Souhlasím s geekosaurem, že velikost by měla být násobkem velikosti bloku, která je často 4K.

Pokud chcete najít velikost bloku stat -c "%o" filename, Je pravděpodobně nejjednodušší možností.

Ale řekněte, že děláte dd bs=4K, To znamená, že to dělá read(4096); write(4096); read(4096); write(4096)...

Každé systémové volání zahrnuje přepínač kontextu, který zahrnuje určitou režii, a v závislosti na plánovaném I/O, čtení s přerušovanými zápisy může způsobit, že disk provede spoustu vyhledávání. (Pravděpodobně nejde o hlavní problém s plánovačem Linuxu, ale přesto o čem přemýšlet.)

Pokud tedy uděláte bs=8K, Umožníte disku, aby přečetl dva bloky najednou, které jsou pravděpodobně blízko sebe na disku, předtím, než budete hledat něco jiného pro zápis (nebo pro servis I/O pro jiný proces) ).

Podle této logiky je bs=16K Ještě lepší, atd.

Chtěl bych tedy vědět, zda existuje horní hranice, kde se výkonnost začíná zhoršovat, nebo pokud je omezena pouze pamětí.

8
Mikel

Jak říká Gilles, můžete určit optimální parametr pro možnost bs na dd pomocí benchmarkingu. To však vyvolává otázku: jak můžete pohodlně srovnávat tento parametr?

Moje předběžná odpověď na tuto otázku je: use dd-opt , nástroj, na kterém jsem nedávno začal pracovat, abych přesně vyřešil tento problém :)

5
sampablokuper

Optimalizoval jsem pro čtečku sdcard usb2.0, která se zdá být nejlepší na bs=10M. Vyzkoušel jsem 4k, na 16M, po 8-10M bez vylepšení. Můžete vidět, jak se snižuje přenosová rychlost ... s největší pravděpodobností v důsledku načtení vyrovnávacích pamětí na zařízení a poté čekání na přenos zařízení na skutečné médium.

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
0
wwright