Inkrementalni komprese

[CPU]

Hodně, dokonce i starých komprimačních programů umí deduplikaci.
Tuším dokonce i stařičké ARJ.
Ale proč to dělat, když stejnou práci zvládne i FS?
Navíc - abys mohl deduplikovat data - potřebuješ vytvořit archiv obsahující co nejvíc souborů.
Tj. měl bys XY archivů nebo bys pořád musel vybavolovat a balit data třeba za rok... 
Proč, když to zvládne FS?

[Reklama]

[Logik]

Deduplikace na FS nebude fungovat moc dobře. Protože když mu někdo do souboru něco vloží, tak se to celý posune a bloky už identický nebudou.

[APhacker_mob]

Ukladal bych jen patche z htmldiff. Pripadne to verzoval gitem. Pokud se jedna o stale stejnou stranku s malym mnozstvym zmen.

[Vít Šesták (v6ak)]

Je fakt, že u toho primitivního řetězení gzipu by reduplikace fungovala jen maximálně v rámci přidaných dat. Prostě to nebude příliš efektivní s malými bloky přidaných dat.

[CPU]

Deduplikace na FS nebude fungovat moc dobře. Protože když mu někdo do souboru něco vloží, tak se to celý posune a bloky už identický nebudou.

Tak třeba týden, kdy v pondělí se změní zdroj:
2MB dat + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb
Tj. úspora: 12 MB
Pak se ti posune offset:
2MB dat + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb + změna 4kb
A začínáš zase znova....takže buď v klidu, deduplikace bude fungovat docela slušně.
Pokud se to uprostřed mění zřídka, bude úspora ohromná.
Jen je potřeba uříznout hlavičku a zajistit, aby to začínalo vždy stejně - (zajistíš uříznutím hlavičky - hlavičku řežeš proto, aby ti obsah začínal vždy stejně).

A navíc - to bude na úrovni FS transparentní, žádné balení a rozbalení, žádné skripty, můžeš to mít v jednom adresáři za dvacet let, nemusíš nic balit.

Příklad: 1x týdně se to celé změní:
Máš 52 týdnů * 2 MB = 104 MB ročně na tento soubor (adresář), který by jinak měl asi 750 MB.
Navíc, pokud se ti změní věta bez posunu - tomu by se dalo pomoct odebráním HTML dekorací a zarovnáním, tak z toho budeš mít třeba 10-20 MB za rok. Tak to klidně můžeš držet na SSD.

Problém mohou být ty PDF, ty bude těžší zpracovat - leda je převést na HTML, možná něčím jako poppler-utils (neznám) Odebrat z toho dekorace a zase by to mohlo jít deduplikovat.

[Reklama]

[CPU]

Ukladal bych jen patche z htmldiff. Pripadne to verzoval gitem. Pokud se jedna o stale stejnou stranku s malym mnozstvym zmen.

Výhoda deduplikace na úrovni FS je transparentnost, kdy máš přístup ke všem souborům a verzuje se to samo.
Navíc pouhým překopírováním na jiný FS z toho vyrobíš původní obsah.
Taky se to dá mimořádně rychle vyzkoušet, jen správně oddělit hlavičku a body, vzniknout soubory .heat a .content, které jsi schopný skriptem klidně zase spojit. No a pak koukat, jak deduplikace maká za tebe.

Výhoda htmldiffu je to, že tě netrápí zarovnání na sektory, ale cirkus okolo toho bude předpokládám(nevím) větší.
Další nevýhoda, proti jaké verzi to chceš kontrolovat? Vždy proti té poslední? Pak se ti ten vláček snadno rozbije...

[mhi]

Appendovani gzipu bohuzel nic neresi, neprebira se stav kompresoru z minula.

Deduplikace na urovni bloku fungovat dle meho nazoru nebude, jak pise Logik. Predstavte si, ze dokument vznika tak, ze nekdo hodi do Wordu nejakou tabulku a texty, doplni tam nekam nahodne volne poznamky a pak z toho udela PDF. Nebo v tom HTML neco upravi. Vznikaji ruzne nahodne posuny o par bajtu, apod.

U tech ruznych diffu je problem "proti cemu diffovat". Ono to bohuzel neni tak,ze by ty "stejne" dokumenty sly po sobe. Ja si stahnu 50 PDFek a do doby nez je otevru nejsem schopen rict, kdo je udelal-jaky "format" maji, a v jake nalade byl zrovna ten clovek.

[CPU]

Vysvělil jsem ti, co s tím máš dělat.
Zkouška jednoduchá
Myslet = houby vědět.

[RDa]

Výhoda deduplikace na úrovni FS je transparentnost, kdy máš přístup ke všem souborům a verzuje se to samo.
Navíc pouhým překopírováním na jiný FS z toho vyrobíš původní obsah.
Taky se to dá mimořádně rychle vyzkoušet, jen správně oddělit hlavičku a body, vzniknout soubory .heat a .content, které jsi schopný skriptem klidně zase spojit. No a pak koukat, jak deduplikace maká za tebe.

Tak to bych transparentnim vubec nenazyval. Zadny head a body neni mozny, kdyz se ti pridavaji radky / meni texty, na nekolika mistech dokumentu.

FS-dedup je nejhorsi napad pro problem tazatele. Ty soubory nejsou blokove orientovane! (napr. nejsou to obrazy disku, kde by takova vec mohla fungovat, pokud se do obrazu neco sem tam pridava a meni).

[RDa]

U tech ruznych diffu je problem "proti cemu diffovat". Ono to bohuzel neni tak,ze by ty "stejne" dokumenty sly po sobe. Ja si stahnu 50 PDFek a do doby nez je otevru nejsem schopen rict, kdo je udelal-jaky "format" maji, a v jake nalade byl zrovna ten clovek.

Pokud chces sledovat "vlakna" ale zpravy chodi nahodne, tak ti nezbyva nic jineho, nez udelat pdf2text a hledat nejvetsi zhodu s nekterym z vlaken ktere sledujes (holt musis novy dokument porovnat bud se vsema predchozima souborama, nebo poslednim z kazdeho vlakna). Kdyz budes delat vsechna, tak ti nalezne i vhodnejsi parent-doc k bindiffu, pokud by match nebyl na poslednim souboru z daneho vlakna (teoreticky nejpodobnejsim - nejmene zmen).. a budes to mit stromovity.

Ale nechapu v jakych radech se tady pohybujeme, ze tohle zrovna je potreba resit - proc nejde vzit vetsi/rychlejsi disk.

[CPU]

Zadny head a body neni mozny, kdyz se ti pridavaji radky / meni texty, na nekolika mistech dokumentu.

Prosím, nereaguj na mě!
Jak ti to říkal ZAJDAN?

kazdy den stahuji z internetu nejaka data, jedna se o plaintext HTML stranku, kde je dlouhatanska tabulka, ktera se ale meni nejen na konci, ale vyjimecne i uprostred.

Pokud se změní uprostřed a dojde k posunu, pak se jen uloží nová verze.
Vyjímečně asi není každý den že? Tj. úspora zde bude zřejmě ohromná, větší než kompresí.
Pokud by se to uprostřed měnilo 1x za 30 dnů, budeš mít poměr cca 1 ku 29, tj. 1x uložíš 2MB a dalších 29 * 2 MB = cca 58 MB ušetříš.

[pruzkumbojem]

ZFS deduplication works on blocks (recordlength) it does not know/care about files. Each block is checksummed using sha256 (by default changeable). If the checksum matches an other block it will just reference the same record and no new data will be written. One problem of deduplication with ZFS is that checksums are kept in memory so large pools will require a lot of memory. So you should only apply reduplication when using large record length

Deduplikace na FS nebude fungovat moc dobře. Protože když mu někdo do souboru něco vloží, tak se to celý posune a bloky už identický nebudou.

[CPU]

kazdy den stahuji z internetu nejaka data, jedna se o plaintext HTML stranku, kde je dlouhatanska tabulka, ktera se ale meni nejen na konci, ale vyjimecne i uprostred.

Když se ti to změní uprostřed

ale vyjimecne i uprostred

tak se ti jen znova uloží celá verze ne?

BTW, u nás je výjimečně = občas, zřídka, ne každých pár dnů. 

Nešňupejte tolik ten kokeš 

[mhi]

Vysvělil jsem ti, co s tím máš dělat.
Zkouška jednoduchá
Myslet = houby vědět.

No vidite, a ja jsem tak hloupy, ze jsem vasi radu neprijal a dale se ji nebudu zabyvat. Jsme zvlastni lide, co? Jako kdybychom kazdy zili v nejake paralelni realite .

Ale nechapu v jakych radech se tady pohybujeme, ze tohle zrovna je potreba resit - proc nejde vzit vetsi/rychlejsi disk.

Hrubym odhadem bych rekl, ze ta "knihovni komprese" muze byt treba 1:500, takze mi to prijde zajimave se tim chvili zabyvat. PDFka prevadet do textu nelze, ztrati se informace, nefunguje to dobre. Spousta programu treba neumi (a asi nemuze umet) kdyz je embeddnuty zmrseny font ze znaky neodpovidaji ASCII/UTF-8 a neni tam mapa. U tech PDFek je problem, ze PostScript uvnitr pocita fixne se souradnicemi, mozna by ale sel napsat program, ktery to nejak relativizuje, pak by mohla fungovat nejak "knihovni" komprese alespon na prunicich stranek.

[RDa]

Zadny head a body neni mozny, kdyz se ti pridavaji radky / meni texty, na nekolika mistech dokumentu.

Prosím, nereaguj na mě!
Jak ti to říkal ZAJDAN?

Zadost se zamita. Nevim o cem mluvis, ale jsi vedle jak ta jedle s tou deduplikaci. Delas jenom tobe vyhovujici predpoklady, ktere jsou na mile vzdalene situaci tazatele co se tyce podoby dat.