Czy istnieje sposób na określenie optymalnej wartości parametru bs do dd?

Czasami widziałem komentarze online w stylu „upewnij się, że ustawiłeś„ bs = ”, ponieważ wartość domyślna potrwa zbyt długo”, i moje własne, bardzo nienaukowe doświadczenia, „cóż, wydawało się, że zajęło to dłużej niż inne czas w zeszłym tygodniu ”wydaje się to potwierdzać. Dlatego za każdym razem, gdy używam „dd” (zwykle w zakresie 1-2 GB), muszę podać parametr bajtów. Mniej więcej w połowie przypadków używam wartości określonej w dowolnym internetowym przewodniku, z którego kopiuję; przez resztę czasu wybiorę liczbę, która ma sens z listy „fdisk -l” dla tego, co zakładam, że jest wolniejszym nośnikiem (np. karta SD, na której piszę).

Czy w danej sytuacji (rodzaj nośnika, rozmiary magistrali lub cokolwiek innego ma znaczenie), czy istnieje sposób na określenie „najlepszej” wartości? Czy łatwo to ustalić? Jeśli nie, to czy istnieje prosty sposób na uzyskanie 90-95% drogi? A może „po prostu wybierz coś większego niż 512” to nawet poprawna odpowiedź?

Myślałem o samodzielnym wypróbowaniu eksperymentu, ale (oprócz tego, że mam dużo pracy) nie jestem pewien, jakie czynniki wpływają na odpowiedź, więc nie wiem, jak zaprojektować dobry eksperyment.

ddpochodzi z przeszłości, kiedy trzeba było tłumaczyć stare taśmy na komputerach mainframe IBM, a rozmiar bloku musiał odpowiadać rozmiarowi użytemu do zapisu taśmy, w przeciwnym razie bloki danych zostaną pominięte lub obcięte. (Taśmy 9-ścieżkowe były wybredne. Ciesz się, że już dawno nie żyją.) Obecnie rozmiar bloku powinien być wielokrotnością rozmiaru sektora urządzenia (zwykle 4KB, ale na bardzo niedawnych dyskach może być znacznie większy i bardzo mały kciuk dyski mogą być mniejsze, ale 4KB jest rozsądnym środkowym punktem niezależnie), a im większy, tym lepsza wydajność. Często używam bloków wielkości 1 MB z dyskami twardymi. (Mamy także o wiele więcej pamięci, którą można teraz rozrzucać.)

Jest tylko jeden sposób na określenie optymalnego rozmiaru bloku, i to jest punkt odniesienia. Właśnie zrobiłem szybki test porównawczy. Komputer testowy to komputer z systemem Debian GNU / Linux, z jądrem 2.6.32 i coreutils 8.5. Oba zaangażowane systemy plików to ext3 na woluminach LVM na partycji dysku twardego. Plik źródłowy ma 2 GB (a dokładniej 2040000 kB). Buforowanie i buforowanie są włączone. Przed każdym uruchomieniem opróżniłem pamięć podręczną sync; echo 1 >|/proc/sys/vm/drop_caches. Czasy przebiegu nie obejmują finału syncdo opróżnienia buforów; finał synczajmuje 1 sekundę. Te sameprzebiegi były kopie na tym samym systemie plików; te diffprzebiegi były kopie do plików na innym dysku twardym. W celu zachowania spójności podane czasy to czasy zegara ściennego uzyskane ztimenarzędzie w kilka sekund. Uruchomiłem każdą komendę tylko raz, więc nie wiem, jak duża jest rozbieżność w czasie.

             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

Wniosek: duży rozmiar bloku (kilka megabajtów) pomaga, ale nie dramatycznie (znacznie mniej niż się spodziewałem dla kopii na tym samym dysku). A cati cpnie działają tak źle. Z tymi liczbami nie ddwarto się przejmować. Idź z cat!

Zgadzam się z geekozaurem, że rozmiar powinien być wielokrotnością rozmiaru bloku, który często wynosi 4K.

Jeśli chcesz znaleźć rozmiar bloku, stat -c "%o" filenamejest to prawdopodobnie najłatwiejsza opcja.

Ale powiedz, że tak dd bs=4K, to znaczy, że read(4096); write(4096); read(4096); write(4096)...

Każde wywołanie systemowe wymaga przełącznika kontekstu, co wiąże się z pewnym narzutem i, w zależności od harmonogramu we / wy, odczytywanie z rozproszonymi zapisami może spowodować, że dysk wykona wiele prób. (Prawdopodobnie nie jest to poważny problem z harmonogramem Linuksa, ale mimo to coś do przemyślenia.)

Jeśli to zrobisz bs=8K, pozwalasz dyskowi na odczyt dwóch bloków naraz, które prawdopodobnie są blisko siebie na dysku, zanim zaczniesz szukać innego miejsca do zapisu (lub obsługi I / O dla innego procesu).

Zgodnie z tą logiką bs=16Kjest jeszcze lepsza itp.

Chciałbym więc wiedzieć, czy istnieje górna granica, w której wydajność zaczyna się pogarszać, lub jeśli ogranicza ją tylko pamięć.

Jak mówi Gilles, możesz określić optymalny parametr dla opcji bs do dd poprzez testowanie. To jednak nasuwa pytanie: w jaki sposób można wygodnie przeprowadzić analizę porównawczą tego parametru?

Moja wstępna odpowiedź na to pytanie brzmi: użyj dd-opt , narzędzia, nad którym niedawno zacząłem pracować, aby dokładnie rozwiązać ten problem :)

Zoptymalizowałem czytnik kart SD usb2.0, który wydaje się działać najlepiej bs=10M. Próbowałem 4k, do 16M, po 8-10M bez poprawy. Możesz zobaczyć, jak zmniejsza się szybkość przesyłania danych ... najprawdopodobniej z powodu załadowania buforów na urządzeniu, a następnie oczekiwania na przeniesienie urządzenia na rzeczywisty nośnik.

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