Kazí se archivy 7z?

[Johnny]

Konverze CRLF/LF?

[Reklama]

[Honza1Ubuntu]

ByCzech

To prave spis ne ne - naopak spis zdechne v prubehu. Pamet VIRT si alokuje na zacaatku, a neresi moc, jestli je dostatek. Pamet RES az v prubehu a jak pamet RES stoupa, nekdy v prubehu komprimace proste zdechne.

Taky jsem to vyzkousel, a prave az po urcite dobe, kdy presahne pamet RES volne misto v RAM, to zdechne. Tedy v pripade, ze potrebna pamet je priblizne stejne velka, jako pamet, co je k dispozici. A to jak u stare, tak i nove verze. Hlaska k tomu je uplne stejna.

Kdyz je ale velikost slovniku o dost vetsi, nez co se vejde do RAM. tak to 7zip pozna a zahlasi hned na zacatku, proces se zastavi.

Takze vlastne jak kdy.

Právě jsem to vyzkoušel. Když to přeženu s velikostí slovníku, skončí to hned při startu na tuhle chybu:

Kód: [Vybrat]

ERROR: Can't allocate required memory!

[Honza1Ubuntu]

Konverze CRLF/LF?

O zaheslovane archivy se nejedna. U tech se zepta na heslo, v pripade nohup napise jako chybu spatne heslo (pri nohup neceka na vstup).

[Honza1Ubuntu]

kdyz komprimuje, tak pise do stejne pojmenovaneho, ale rozpracovaneho nedokonceneho souboru nebo ma pracovni jmeno? jestli jo, tak to bude nepoznatelny, kdyz to zabije oom, tak to neni vada 7zip, ale spravce.

Pravdepodobne to bude cele reseni. Pri vytvareni archivu nejak dosla pamet, coz se muze stat nahlym spustenim jineho procesu navic, i kdyz by pamet dojit nemela. &z pak pri vycerpani RAM padne. A nekdy se nesmaze rozpracovany nedodelany archiv,i kdyz by mel. A kdyz to jede prez nohup, neni poznat nic.

Rozpracovany archiv ma stejne jmeno a neni poznat ze je nedokoncen. Nektera data k  archivu (filelist, typ komprese pod.) se pravdepodobne ukladaji az na konec archivu.

Pri kontrole ve Win32 s nedostatkem pameti (Pri 1024 MB slovniku je potreba je na kontrolu okoko 2,2 GB +Filelist) napsal 7z ze nestaci pamet, a tak jsem archiv ignorovoal, coz byla chyba. Dva zkazene archivy maji okolo milionu suboru, ale dalsi zkazene archivy tolik souboru nemaji.

Opravovat ma smysl mozna jeden archiv, ale asi by to vubec nebylo jednoduche, co jsem hledal.

[ByCzech]

A kdyz to jede prez nohup, neni poznat nic.

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

Kód: [Vybrat]

7-Zip returns the following exit codes:

              0      Normal (no errors or warnings detected)

              1      Warning (Non fatal error(s)). For example, some files cannot be read during compressing. So they
                     were not compressed

              2      Fatal error

              7      Bad command line parameters

              8      Not enough memory for operation

              255    User stopped the process with control-C (or similar)

[Reklama]

[Honza1Ubuntu]

A kdyz to jede prez nohup, neni poznat nic.

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

No jo, kdyz uz si clovek myslel, ze skript funguje OK a presmeroval nohup dp /dev/null . Bez presmerovani jde vystup do nohup.out . On je ten soubor nekdy i docela velky a presmerovani do /dev/null setri systemove prostredky.

Mozna tam i nohup.out byl, ale pak jsem ho smazal s tim, ze vse je OK. Malokdo si zalohuje vystupy z terminalu.

[ByCzech]

A kdyz to jede prez nohup, neni poznat nic.

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

No jo, kdyz uz si clovek myslel, ze skript funguje OK a presmeroval nohup dp /dev/null . Bez presmerovani jde vystup do nohup.out . On je ten soubor nekdy i docela velky a presmerovani do /dev/null setri systemove prostredky.

Mozna tam i nohup.out byl, ale pak jsem ho smazal s tim, ze vse je OK. Malokdo si zalohuje vystupy z terminalu.

I když je nohup vystup přesměrovaný do /dev/null tak to vrací exit code, který se přečte v $?

[P_V]

Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.

[Milan Straka]

7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z

Podle man lzma (viz CompMem; je to sice LZMA2, ale myslím, že to sedí i na 7z) je skutečná spotřeba paměti při kompresi asi desetinásobek velikosti slovníku -- určitě bylo na stroji, kde se to komprimovalo, 10GB RAM? Pokud ne, tak to po zkomprimování příslušně velké části vstupu (něco jako velikost RAMky děleno deseti) zhavarovalo na nedostatek paměti.

[Honza1Ubuntu]

Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:

Kdyz poustim nohup, tak je to proto, ze terminal-putty muzu zavrit a proces bezi dal. Pak se da vystup najit v nohup.out, pokud to nepresmeruji jinam (do /dev/null/)

[Honza1Ubuntu]

7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z

Podle man lzma (viz CompMem; je to sice LZMA2, ale myslím, že to sedí i na 7z) je skutečná spotřeba paměti při kompresi asi desetinásobek velikosti slovníku -- určitě bylo na stroji, kde se to komprimovalo, 10GB RAM? Pokud ne, tak to po zkomprimování příslušně velké části vstupu (něco jako velikost RAMky děleno deseti) zhavarovalo na nedostatek paměti.

RAM je dostatek, LZMA pri tomto slovkiku vezme 10,7 GB RAM, LZMA2 o neco mene (rozdil je tusim jen okolo 100-200 MB), celkem cca 11x nasobek slovniku. K dispozici je 16 MB RAM nebo i 32 GB RAM tak se to vejde OK (pri 16 GB RAM to zabere 67%). K tomu se ale jeste pricte filelist, coz je okolo 1-2 GB na milion souboru. Az na par extremu se to vejde vzdy i do tech 16 GB.

[Lol Phirae]

Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.

Můžeš, ale tazatel na tebe evidentně sere a je přesvědčen o genialitě své kompresní metody, která podle něj sežere pouhých 10+GB RAM jen na ten slovník, což je úplně OK. 

[Jenda]

V tom případě by měla kontrola partition odhalit hnilobu v souboru

Neměla. Mohlo se to poškodit třeba vadnou RAM při kopírování. A kromě btrfs a ZFS nedělá žádný souborový systém kontrolu dat, která tu vadnou RAM většinou pomůže odhalit.

Konverze CRLF/LF?

O zaheslovane archivy se nejedna.

Jak souvisí potenciální poškození LF/CRLF s nějakým šifrováním o úroveň výš?

Jine soubory pokazene nemam.

Jak to poznáš? Některé soubory mají uvnitř checksumy, ale u spousty na první pohled nějaký jeden bitflip uprostřed vůbec nepoznáš.

Na chybu disku to nevypada, protoze jak prekopirovani souboru jinam, tak cteni a zipis na disk jde velice svizne bez problemu.

Disky, řadiče, procesory, ... s vadnou pamětí fungují úplně stejně jako ty v pořádku, jenom jednou za dlouho přehodí nějaký bit.

Presunuti jde bez jakychkoliv zaseku, ale pak pri pokusu otevrit/rozbalit/zkontrolova archiv to zahlasi, ze se nejedna o 7z archiv.

Jako že zkopíruješ funkční archiv a na kopii to řekne, že to není archiv? Porovnej SHA256 hashe těch souborů a pak to binárně diffni… (předtím se možná vyplatí zahodit pagecache, echo 3 > /proc/sys/vm/drop_caches)

[Honza1Ubuntu]

Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.

Uspora je jak kdy, podle typu dat a rozsahu podobnosti. U velkeho mnozstvi souboru je uspora 1024 MB slovnik oproti 64 MB slovkik 10-30 %, vyjimecne i 70% u specifickych dat. V naproste vetsine pripadu je vysledny archiv mensi minimalne (1-5 %), u obrazku pod 1% . Ale pamet by dojit jen tak nemela, i kdyz v par pripadech asi ano, pricina muze byt i jinde. Hlavni chybou je nedumyslna kontola dat.

Ad. Lol Phirae spamer. Tazatel na dotaz nesere, jen su nevsiml, ktere prispevky jsou nove.

[Honza1Ubuntu]

Jine soubory pokazene nemam.

Jak to poznáš? Některé soubory mají uvnitř checksumy, ale u spousty na první pohled nějaký jeden bitflip uprostřed vůbec nepoznáš.

Jako že zkopíruješ funkční archiv a na kopii to řekne, že to není archiv? Porovnej SHA256 hashe těch souborů a pak to binárně diffni… (předtím se možná vyplatí zahodit pagecache, echo 3 > /proc/sys/vm/drop_caches)

Kdyz dam kontrolu vsech archivu, tak to hodi porad ty same chybne (pravdepodobne chybne od vytvoreni pred cca 2 roky). Kontrola archivu by mela chyby odhalit. Kdyz zkopiruju funkcni archiv, porad je funkcni a soubory se binarne nelisi.

Naopak archiv, ktery ma chybu, tak ma chybu i na jinych mistech (zalohy). Muselo dojit k chybe pred 2 lety, na jinem PC, pred presunem na externi disk.

Zaheslovani neni chyba, to proste 7z napise spatne heslo. Jinak pri rekurzivni kontrole 7z t slozka/ to bere jako archivy vsechny soubory, bez ohledu na priponu. Tedy kdyz se u archivu zmeni pripona na avi, stejne to pozna ze jde o archiv a testuje to jako archiv (mimo jine zmenou pripony archiv, byt zaheslovany se rovnez neda ukryt).

Naopak u souboru,ktere archivy nejsou se to snazi otevrit jako archiv a hodi to hlasku, chyba, soubor neni archiv, bezohledu na priponu.

Rekurzivni kontrolu umi jen novy 7z (z roku 2016) , starsi verze ne.