🚀 go-pugleaf

at Tue 19 of Jan 2010 15:56, PetruS wrote:

> Bodek wrote:
> 
>> at Tue 19 of Jan 2010 11:48, PetruS wrote:
>> 
>>> Bodek wrote:
>> Ale problem w tym, że obraz iso (z podfolderów
>> dyskowych na /5/v) spakowany pkuzip-em daje
>> większy plik i tylko o to mi chodzi:
>> 
>> #ls -hl /tmp/2/
>> -r-xr-xr-x   1 root  wheel    68M 10 Jan 10:02 frenzy.uzip #
>> oryginalny
>> -r-xr-xr-x   1 root  wheel    87M 14 Jan 04:24 f2.uzip* # po
>> rozpakowaniu frenzy.uzip i spakowaniu
>> 
>> Reasumując - problem zaczyna się już w momencie kopiowania CD na HD
>> a kończy na spakowaniu pkuzipem.

Takie dobre założenia, a kompletnie przeoczyłem 
parametr '-s' w mkuzip :-)

>> 
>> Rozwiązanie widzę w niestandardowym utworzeniu file systemu
>> na HD przed skopiowaniem zawartości CD (tego z obrazu),
>> albo niestandardowym tworzeniem obrazu ISO  - używam
>> 'mkisofs -v -R -U ...', taki alias utworzyłem przed laty
>> i zawsze działało jak trzeba. Teraz też nie widzę, jaki
>> mogłoby to mieć wpływ na puchnięcie pliku wynikowego.
> 
> Musisz dobrze dobrać parametr -s dla mkuzip.
> 
> Polecenie:
> 
> # mkuzip -s 1024 -o obraz.uzip obraz.iso
> 
> da Ci wiele większy plik wynikowy niż standardowo (bez -s).
> 
> Natomiast -s ustawione na maksa (1024 * 128 - 512) da obraz
> najmniejszy, ale ciut wolniejszy w użyciu.
> 
> Pokombinuj więc z doborem tego parametru.

Maksymalny cluster daje w wyniku plik 72 MB, 
wobec 79 przy domyślnym i 68 MB oryginalnego pliku.
Znaczący postęp.
Dzięki!


To już drugi problem w ostatnim czasie, którego rozwiązaniem jest 
zwiększenie wielkości łopaty do przenoszenia danych.
Znaczy wypada potrenować blok-size w newfs. Domyślna 
jego wartość jest taka sama jak cluster w mkuzip :-)


-- 
Bodek