2009-08-30 6 views
5

Mam skrypt, który tworzy system plików w pliku na komputerze z systemem Linux. Widzę, że aby stworzyć system plików, używa on opcji "dd" z opcją bs = x, czyta z/dev/zero i zapisuje do pliku. Myślę, że zwykle określanie ibs/obs/bs jest przydatne do odczytu z rzeczywistych urządzeń sprzętowych, ponieważ ma on określone ograniczenia rozmiaru bloku. W tym przypadku jednak, ponieważ odczytuje z urządzenia wirtualnego i zapisuje do pliku, nie widzę żadnego sensu z opcją "bs = x bytes". Czy moje rozumienie jest tutaj błędne? (Na wszelki wypadek, jeśli pomaga, ten system plików jest później używany do rozruchu qemu vm)Cel ibs/obs/bs w dd

Odpowiedz

3

Wielkość bloku to liczba bajtów, które są odczytywane i zapisywane na raz. Przypuszczalnie istnieje opcja count=, która jest określona w jednostkach rozmiaru bloku. Jeśli istnieje opcja skip= lub seek=, będą one również w jednostkach o rozmiarze bloku. Jeśli jednak czytasz i zapisujesz zwykły plik, a nie ma błędów dysku, rozmiar bloku nie ma znaczenia, o ile możesz odpowiednio skalować te parametry i nadal są one liczbami całkowitymi. Jednak niektóre rozmiary mogą być bardziej wydajne niż inne.

+1

Masz rację czas dd if =/dev/zero of = myfile bs = 1024 count = 1024 sys \t 0m0.020s czasu dd if =/dev/zero of = myfile bs = 1 count = 1048576 sys \t 0m8.381s – Methos

2

Do odczytu z/dev/zero, nie ma znaczenia. ibs/obs/bs określają liczbę odczytanych bajtów na raz. Pomocne jest wybranie numeru na podstawie sposobu, w jaki bajty są odczytywane/zapisywane w systemie operacyjnym. Na przykład Linux zwykle czyta z twardego dysku w 4096 bajtowych porcjach. Jeśli masz jakieś pojęcie o tym, jak podstawowy sprzęt odczytuje/zapisuje, dobrym pomysłem może być określenie ibs/obs/bs. Przy okazji, jeśli podasz bs, zastąpi on wszystko, co określisz dla ibs i obs.

10

Aby zrozumieć rozmiary bloków, musisz znać napędy taśm. Jeśli nie jesteś zainteresowany napędami taśmowymi - na przykład, nie myślisz, że kiedykolwiek zamierzasz użyć jednego z nich - wtedy możesz teraz wrócić do snu.

Pamiętasz napędy taśm z filmów z lat 60., 70., może nawet 80.? Te, w których kołowrotek wirował, i tak dalej? Nie twój Exabajt, ani nawet QIC - ćwierćcalowe naboje - taśmy; twoje dobre, staroświeckie, szpulowe napędy taśmowe na szpulę? Na tym liczył się rozmiar bloku.

Dane na taśmie zostały zapisane w blokach. Każdy blok został oddzielony od siebie odstępem między rekordami.

----+-------+-----+-------+-----+---- 
... | block | IRG | block | IRG | ... 
----+-------+-----+-------+-----+---- 

W zależności od sprzętu i oprogramowania napędu taśmowego mogło wystąpić wiele problemów. Na przykład, jeśli taśma została zapisana z rozmiarem bloku 5120 bajtów i czytasz taśmę o rozmiarze bloku 512 bajtów, to napęd taśm może odczytać pierwszy blok, zwróci ci 512 bajtów, a następnie odrzuci pozostałe dane; następny odczyt rozpocznie się w następnym bloku. I odwrotnie, jeśli taśma została zapisana z rozmiarem bloku 512 bajtów i zażądałeś bloków o długości 5120 bajtów, otrzymasz krótkie odczyty; każdy odczyt zwróciłby tylko 512 bajtów, a jeśli twoje oprogramowanie nie zwracałoby uwagi, to czytasz śmieci. Pojawił się również problem polegający na tym, że napęd taśmowy musiał wstać, by odczytać blok, a następnie zwolnić. Sztuka ASCII sugeruje, że IRG był mniejszy niż bloki danych; niekoniecznie tak było. I zajęło mi trochę czasu, aby przeczytać jeden blok, przerwać IRG, przewinąć do tyłu, aby przejść do następnego bloku i zacząć od nowa. A jeśli napęd taśm nie ma pamięci do buforowania danych - te tańsze nie - można poważnie wpłynąć na wydajność napędu taśmowego.

Historia wojny: praca przygotowana na nowszej maszynie z nieco bardziej nowoczesnym napędem taśmowym. Napisałem taśmę za pomocą programu tar bez sensownego rozmiaru bloku (czyli domyślnie 512 bajtów). To było duże oprogramowanie - musiało być, oh, mniej niż 100 MB w sumie (dawno temu, innymi słowy). Taśma napisała ładnie, ponieważ maszyna była wystarczająco nowoczesna i zajęło to zaledwie kilka sekund. Ale musiałem ściągnąć materiał z taśmy na maszynie ze starszym napędem taśmowym, który nie miał żadnego bufora na pokładzie.Tak więc, przeczytał materiał, 512 bajtów na raz, a kołowrotek zakołysał się do przodu, czytając jeden blok, a następnie kołysał z powrotem wszystkie, ale może pół cala, a następnie czytał w przód, aby przejść do następnego bloku, a następnie kołysał się z powrotem, i ... cóż, widać, że to robi, a ponieważ przeczytanie każdego bloku o długości 512 bajtów zajęło znaczną część sekundy, całkowity czas był przerażający. Mój lot miał odejść ... i musiałem też zebrać te dane. (Było to wystarczająco dawno temu, a w odległej krainie, zmiany w ostatniej chwili na loty również nie były zbyt dużą opcją.) Krótko mówiąc, przeczytano - ale gdybym użył rozsądny rozmiar bloku (na przykład 5120 bajtów zamiast domyślnego 512), zostałbym zrobiony znacznie, dużo szybciej i znacznie mniej niebezpiecznie, by nie zaginąć samolotu (ale faktycznie złapałem samolot, może z 20 minut do stracenia, pomimo przejazdu taksówką przez Paryż w godzinach szczytu).

W przypadku bardziej nowoczesnych napędów taśmowych było wystarczająco dużo pamięci na dysku, aby buforować i uzyskać napęd taśmowy do przesyłania strumieniowego - zapisywanie w sposób ciągły bez odwracania - było możliwe. Kiedyś używałem rozmiaru bloku, takiego jak 256 KB, aby pobierać strumienie QIC. Ostatnio nie zrobiłem wiele z napędami taśmowymi - zobaczmy, nie tysiąclecie i niewiele za kilka lat wcześniej; na pewno nie za dużo, ponieważ CD i DVD stały się mechanizmami wyboru oprogramowania (gdy nie korzystano z pobierania elektronicznego).

Ale rozmiar bloku naprawdę miał znaczenie w dawnych czasach. I dd zapewniało dobre wsparcie dla niego. Można nawet przesłać dane z napędu taśmowego, który został napisany z, na przykład, blokiem 4 KB na inny, który chciałbyś napisać z, powiedzmy, blokami 16 KB, określając ibs (rozmiar bloku wejściowego) niezależnie od obs (blok wyjściowy rozmiar). Cholernie użyteczne!

Parametr count jest również pod względem rozmiaru (wejściowego) bloku. Przydawało się "dd bs=1024 count=1024 if=/dev/zero of=/my/file/of/zeroes", aby skopiować 1 MB zer. Lub, aby skopiować 1 MB pliku.

Znaczenie dd jest znacznie zmniejszone; była istotną częścią zbrojowni dla każdego, kto pracował z napędami taśmowymi dziesięć lat temu.

+0

To naprawdę fajna historyczna perspektywa i fajna anegdota. "Znaczenie dd jest znacznie zmniejszone" ... Czy miałeś na myśli "Znaczenie dd jest znacznie * niedocenione *"? lub "Znaczenie dd * znacznie się zmniejszyło". BTW cokolwiek powiedzieliście, ma sens w przypadku rzeczywistych urządzeń hw, w których dane są zapisywane w jednym formacie, należy je czytać i pisać w innym. To, o co szczególnie proszę, to czytanie z pseudo urządzenia i pisanie do pliku. – Methos

+0

Prawdopodobnie zarówno niedoceniany, jak i pomniejszony. Od dawna nie potrzebuję poważnie używać 'dd'. Jeśli tworzony plik jest plikiem dysku, to jeśli rozmiar zostanie określony prawidłowo, rozmiar bloku może nie mieć znaczenia - ale może zapewnić niewielką optymalizację wydajności. Domyślny rozmiar bloku w 'dd' jest prawdopodobnie nadal mały (512 bajtów), a dzięki określeniu większego rozmiaru ogólna wydajność może zostać zwiększona. Ale prawdopodobnie nie jest to krytyczne - jak to miało miejsce w przypadku niektórych napędów taśmowych w dawnych czasach. –

Powiązane problemy