🚀 go-pugleaf

at Sat 26 of Dec 2009 21:05, Wojciech Puchar wrote:

> Bodek <nbody@nowhere.net> wrote:
>> Jest sobie plik - obraz dysku:
>> # ls -lh kde-desktop.img
>> -rw-r--r--  1 root  wheel   675M  4 Sep 19:43 kde-desktop.img
>> który chcemy wrzucić na pendrive (albo SD-memory)
>> 
>> 
>> Kopiujemy przy pomocy dd z pliku na urządzenie:
>> # time dd if=kde-desktop.img of=/dev/da4
>> 1382400+0 records in
>> 1382400+0 records out
>> 707788800 bytes transferred in 3019.911176 secs (234374 bytes/sec)
>> real    50m19.997s
>> user    0m2.207s
>> sys     0m37.142s
> 
> dopisz bs=64k  - albo więcej
> 
> i przeczytaj manuala od dd abyś zrozumiał czemu :) domyślnie jest 512
> bajtów nagrywanie takimi porcjami po prostu nie może być szybkie.

Chyba nie uda się wykręcić ze swojego niezgulstwa, więc spróbuję 
zmienić temat.

O wpływie wielkości bloku na szybkość operacji I/O wiadomo mi
przynajmniej od momentu kiedy pisałem programiki assemblerowe
zmieniające wielkość i sposób buforowania, aby przyśpieszyć
kopiowanie. Z tego samego powodu używałem później xcopy 
w MS-DOS/PC-DOS, a jeszcze później na pl.comp.os.(free)bsd
zadawałem pytanie, jak zmienić wielkość bloku dla cp
(nie było żadnego odzewu).

A teraz właśnie zmiana tematu... Nie wydaje się Wam,
że ostatnio (pół roku?) google jakoś kiepsko znajduje posty
w newsach? Usiłowałem znaleźć to swoje pytanie (jak siebie
znam, słowami kluczowymi byłyby bufor i xcopy) i zero trafień.

A wielkość bufora dla dd zmieniłem na jednomegowy już po paru
minutach jego czołgania się z wartościami domyślnymi.
Zapomniałem jedynie dodać literkę 'k' po 1024.


-- 
Bodek