🚀 go-pugleaf

at Tue 19 of Jan 2010 11:48, PetruS wrote:

> Bodek wrote:
> 
>> at Mon 18 of Jan 2010 12:40, PetruS wrote:
>> 
>>> Bodek wrote:
>>> 
>>> Następnie zamontować podobnie jak montuje się zwykły obraz iso:
>>> 
>>> mount_cd9660 /dev/`mdconfig -af obraz.uzip`.uzip /mnt
>> 
>> Składnię można podejrzeć przeglądając zawartość obraz.uzip
>> i teoretycznie wystarczyłoby:
>>  ./obraz.zip
>> praktycznie nie działa, bo albo nie montuje, albo gubi się
>> na 'kldstat', więc trzeba montować ręcznie.
> 
> Nie montuje się, bo trzeba jeszcze dodać punkt montowania:
> 
> # ./obraz.uzip /mnt
> 
>> Teraz został mały problem, też związany z tematem tego wątku.
>> Jak utworzyć obraz.iso, tak aby nie spuchł o kilkanaście
>> procent objętości.
>> 
>> Na konkretnym przykładzie. Mamy:
>>  http://frenzy.bspu.ru/frenzy/iso/frenzy-1.2-reincarnation-mini-en-
> release.iso
>> z tego pliku wyłuskujemy plik frenzy.uzip. Następnie frenzy.uzip
>> rozpakowujemy, montujemy jako CD o takiej zawartości:
>> 
>> #ls -lF /mnt/v
>> total 85
>> -rw-r--r--   1 root  wheel    798 10 Jan 09:50 .cshrc
>> -rw-r--r--   1 root  wheel    265 10 Jan 09:50 .profile
>> -r--r--r--   1 root  wheel   6206 10 Jan 09:50 COPYRIGHT
>> drwxr-xr-x   2 root  wheel   6144 10 Jan 09:59 bin/
>> drwxr-xr-x   7 root  wheel   4096 10 Jan 09:59 boot/
>> [...]
>> #du -sh /mnt/v
>> 175M    /mnt/v
>> 
>> Aby poprawić coś z tej zawartości, trzeba całość
>> skopiować na HD. Otrzymujemy takie coś:
>> 
>> #ls -lF /5/v
>> total 40
>> -rw-r--r--   1 root  wheel   798 10 Jan 09:50 .cshrc
>> -rw-r--r--   1 root  wheel   265 10 Jan 09:50 .profile
>> -r--r--r--   1 root  wheel  6206 10 Jan 09:50 COPYRIGHT
>> drwxr-xr-x   2 root  wheel  1024 10 Jan 09:59 bin/
>> drwxr-xr-x   7 root  wheel   512 10 Jan 09:59 boot/
>> [..]
>> 
>> #du -sh /5/v
>> 195M    /5/v
>> 
>> 
>> Rzuca się w oczy różnica objętości drzewa plików
>> i liczba bloków systemu plików.
>> Pytanie - jak zminimalizować tę różnicę objętości
>> drzewa plików?
> 
> Rozumiem, że ten pierwszy du był robiony na zamontowanym CD,
> a ten drugi na HD?

Oczywiście.


> A co daje polecenie:
> 
> # du -shA /mnt/v /5/v
> 
> Który teraz jest większy? ;)

Proszę bardzo:
#du -shA /mnt/v /5/v
183M    /mnt/v
179M    /5/v

Ten na dysku jest nawet mniejszy (wykasowane rr_moved)

> Zrób mkisofs dla katalogu na dysku, zamontuj obraz i porównaj wyniki
> du. Zdaduję: będą "takie same" jak dla obrazu frenzy.uzip (/mnt/v)
> wyżej.

Oczywiście (nie wiem, czemu by miało być inaczej):

#du -sh /mnt/x /mnt/v
175M    /mnt/x
175M    /mnt/v

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.

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.


-- 
Bodek