Dotaz: nerovnaka komprimacia

[macrek]

Nazdarek,

Mam takyto skript:

block_size=4955
target_file=file
app_script=app_script

sync
mke2fs -c /dev/ram $block_size
mount -t ext2 /dev/ram /mnt
cp -R root-fs/* /mnt/
umount /dev/ram
dd if=/dev/ram bs=1k count=$block_size of=ext2n
cp ext2n image
gzip -9v -f image
cp -f image.gz $target_file
sync

Problem je v tom, ze ked ho spustim prvykrat (po restarte compu) tak velkost $target_file je okolo 1,1MB (kompresia okolo 77%). Ale ked ho spustim druhykrat tak vysledny subor $target_file je velky uz okolo 1,3MB (kompresia okolo 71%). Potrebujem setrit miestom a 77%tna kompresia je este pripustna, kdezto 71%tna uz nie.

V com moze byt problem ? preco mi to raz skomprimuje tak, raz tak ? Tipujem, ze by mohol byt problem vo filesysteme, ktory vytvaram v /dev/ram, ale nexapem preco, kedze ho vytvaram nanovo.

Odpovědi

[Heron]

A nezmení se mezitím ten root-fs? Nepribudou tam nějaké logy atd?

[macrek]

urcite nie... je to stale to iste..
prvy image po restarte je OK, ale dalsi je uz vacsi...

[Zdenek Stryhal]

Chci se ujistit, ze tomu dobre rozumim. Chces rict, ze prikaz:

gzip -9v -f image

dava spusten dvakrat pokazde jiny vysledek?

[macrek]

nie tak celkom...
chcem povedat, ze ten skript hore dava stale rozny vysledok
prave testujem to, ci ten rozny vysledok dava gzip alebo nieco v skripte nad nim...
ale tipujem to prave na ten gzip, pretoze dd ma presne zadane kolko bytov ma preniest

[Heron]

gzip je deterministicky program, takze pokud dava ruzne vysledky, tak musi byt ruzny vstup. To že dd dává stejný počet bytů nic neznamená, záleží na jejich obsahu a ten bude pro oba případy různý.

[Heron]

Tipujem, ze by mohol byt problem vo filesysteme, ktory vytvaram v /dev/ram, ale nexapem preco, kedze ho vytvaram nanovo.

Tohle možná bude ten problém. Při vytváření se FS nemaže. Tedy předchozí byty tam fyzicky zůstanou (jen se vytvoří nové inody a bitmapy pro prázdný FS). Takže pro další komprimaci se sice vytvoří FS, ale image té partišny není stejný i když ten FS obsahuje stejná data.

Zkuste do toho skriptu vložit vymazání té partišny (dd z /dev/zero)

[macrek]

jo, toto by mohlo pomoct..
aj ked momentalne nechapem, pretoze po tomto restarte to komprimuje stale rovnako. V tom sa determinizmus hlada dost tazko :) pretoze predtym (balim ten root-fs uz asi 30ty krat) s tym stale boli problemy. No nic, pridam tam vymazanie /dev/ram cez dd a uvidime ako sa to bude tvarit.
Zatial dakujem.

[Luboš Luňák]

No jestli je potreba setrit mistem, tak proc gzip misto bzip2? Jinak ja bych na tom nevidel nic divneho, komprimace ruznych veci ma proste ruzne vysledky. Ten cp nema -p, takze se meni timestamps, stejne atime a ext2 bude mit urcite jeste nejake primo v sobe.

[macrek]

Je to troxu komplikovanejsie, bzip2 tam nie je mozne pouzit, pretoze na systeme kde sa to rozbaluje bzip2 neexistuje. Je mi jasne, ze komprimacia roznych veci dava rozne vysledky, lenze /root-fs sa nemeni, a nemyslim, ze timestamps spravi rozdiel v komprimacii o 300kB.

[Heron]

Jak jsem psal, zkuste tam na začátek dát dd if=/dev/zero of=/dev/ram.

[jurko]

presne tak, za riadok:
mke2fs -c /dev/ram $block_size
fuknut napr.:
dd if=/dev/zero of=/dev/ram bs=1k count=$block_size
(vid. napr. http://www.tldp.org/HOWTO/Bootdisk-HOWTO/buildroot.html)

[macrek]

Jo, vyzera, ze to funguje, ze ma to nenapadlo :)
ten qju heron :)

akurat, to dd if=/dev/zero je potrebne dat nie za ale pred
mke2fs
alebo potom za:
dd if=/dev/ram bs=1k count=$block_size of=ext2n

[Heron]

Přicházíme sloužit
[--Mr. Spock]

[msk]

Daj si za to dd md5sum a uvidis ...

[macrek]

jo.. porovnaval som to rucne, je tam rozdiel