abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 19:46 | Nová verze
dnsdist, specializovaný balancer pro DNS provoz, dosáhl stabilní verze 1.2.0. Tento sw vyvíjí komunita kolem PowerDNS a neměl by uniknout pozornosti nikomu, kdo provozuje vytíženější rekurzivní DNS servery. Balancer je vhodný k obraně před DDoS útoky, je skriptovatelný v LUA, disponuje konzolovým rozhraním a má spoustu dalších zajímavých vlastností. … více »
BigWrigley | Komentářů: 0
dnes 15:22 | Nová verze

Byla vydána verze 9.5 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Zdůraznit lze možnost ověřování GPG podpisů u commitů.

Ladislav Hagara | Komentářů: 1
včera 16:22 | Nová verze

Byla vydána verze 0.11.0 softwaru pro statistickou analýzu dat GNU PSPP (Wikipedie), svobodné alternativy k proprietárnímu softwaru IBM SPSS Statistics (Wikipedie). Vedle několika vylepšení a oprav chyb jsou řešeny také 2 bezpečnostní chyby CVE-2017-10791 a CVE-2017-10792. O týden později byla vydána verze 1.0.0 přinášející pouze aktualizaci překladů. Proč verze 1.0.0 a ne například 0.11.1? Dle vývojářů jsou důvody následující:

… více »
Ladislav Hagara | Komentářů: 0
včera 10:35 | Komunita

Na blogu Oracle se objevila zpráva o tom, že plánovaná verze Java EE 8 bude uvolněna jako open source (referenční implementace a compatibility kit). V současné době je uvolněna jen Java SE (standard edition) pod licencí GPLv2 v podobě OpenJDK (Open Java Development Kit), kterou začal v roce 2006 uvolňovat Sun.

Max | Komentářů: 4
21.8. 23:55 | IT novinky

Google na YouTube oficiálně představil Android 8.0 Oreo. Přehled novinek v příspěvku na blogu věnovaném vývojářům.

Ladislav Hagara | Komentářů: 33
21.8. 16:44 | Zajímavý článek

Po téměř 3 měsících od vydání třetího čísla publikoval Michal Špaček na svých stránkách čtvrté číslo newsletteru věnovanému bezpečnosti, bezpečnému vývoji převážně webových aplikací a bezpečnosti uživatelů. Jedná se současně o číslo poslední: "Nepíše se mi to lehce, a trvalo to, než jsem to ze sebe dostal, ale tohle je poslední newsletter v této podobě. Ani jsem ho nestihl pojmenovat a už jsem ho zabil. Nezbývá mi tolik času, abych každou událost, novinku a změnu v prohlížeči detailně popisoval tak, jak bych v newsletteru chtěl, mrzí mě to".

Ladislav Hagara | Komentářů: 2
21.8. 07:00 | Nová verze

Byla vydána diaspora* ve verzi 0.7.0.0. Jedná se o svobodný software, který slouží jako osobní webový server pro poskytování služeb sociální sítě (Wikipedie). Přehled novinek v příspěvku na blogu a na GitHubu. Sociální síť diaspora* byla před pěti lety předána komunitě.

Ladislav Hagara | Komentářů: 0
21.8. 06:00 | IT novinky

Společnost Hardkernel stojící za jednodeskovými počítači ODROID představila na YouTube minipočítač určený pro domácí cloud ODROID-HC1 vycházející z ODROID-XU4. Minipočítač s kovovou krabičkou, do které stačí vložit 2 a půl palcový disk, lze koupit za 49 dolarů. ODROID-HC1 je stohovatelný.

Ladislav Hagara | Komentářů: 39
20.8. 16:22 | Nová verze

Byl vydán DB Browser for SQLite (sqlitebrowser) ve verzi 3.10.0. Nejnovější stabilní verze této grafické nadstavby nad relačním databázovým systémem SQLite (Wikipedie) přináší například integraci s DBHub.io, tj. platformou pro sdílení SQLite databází. Podrobnosti na GitHubu.

Ladislav Hagara | Komentářů: 2
20.8. 08:00 | IT novinky

Andy Rubin, spoluzakladatel společnosti Android, jež byla v roce 2005 koupena Googlem, nyní CEO společnosti Essential Products, oznámil předprodej chytrého telefonu Essential. Telefon se začne rozesílat 1. září. Cena telefonu je 699 dolarů. Cena telefonu současně s 360° kamerou s rozlišením 4K byla stanovena na 749 dolarů. Kameru, v budoucnu i další příslušenství, lze k telefonu připojit pomocí konektoru s magnety.

Ladislav Hagara | Komentářů: 1
Těžíte nějakou kryptoměnu?
 (5%)
 (2%)
 (18%)
 (76%)
Celkem 374 hlasů
 Komentářů: 21, poslední 13.8. 09:57
    Rozcestník

    Dotaz: Výběr deduplikovacího souborového systému

    22.12.2012 13:50 atrak
    Výběr deduplikovacího souborového systému
    Přečteno: 1312×
    Ahoj. Mám backup server s diskovým polem o velikosti 6 TB. Zálohuji na něj servery a klientské stanice. Zálohovaná data (zvlášť u těch stanic) jsou z většiny naprosto totožná, proto chci nasadit na backup server nějaký deduplikační souborový systém. Našel jsem následující možnosti:
    • ZFS
      výhody: zřejmě dost odladěné
      nevýhody: musel bych z linuxu přejít na freebsd nebo třeba na openindiana; na 1 TB dat potřebuje pro deduplikaci až 6 GB RAM
    • SDFS (http://opendedup.org/)
      výhody: ?
      nevýhody: napsané v javě, nemožnost používat příkaz df, většina příkazů vrátí java Exception (to už o kvalitě tohoto fs něco napovídá) - funguje z LANG=C (problém s českou desetinnou čárkou), ..., pro detekci stejných bloků používá hashování
    • LessFS
      výhody: napsané v C
      nevýhody: pro detekci stejných bloků používá hashování
    • DDumbFS
      výhody: napsané v C
      nevýhody: pro detekci stejných bloků používá hashování
    Poslední zkoušený systém DDumbFS je "nejlehčí" - umí jen deduplikaci, což mi vyhovuje. Rovněž funguje spolehlivě (to i LessFS). Nicméně mám zásadní problém s tím, že to používá pro detekci stejných bloků hash funkci => při hash kolizi mohu přijít o data. Co používá ZFS nevím, ale ten jeho paměťový nárok je nesplnitelný.

    Jaký deduplikační systém používáte vy nebo jaký byste mi doporučili?

    Odpovědi

    22.12.2012 13:54 kyytaM | skóre: 35 | blog: kyytaM | Bratislava
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Nie je moznost pouzit zalohovaci SW, ktory robi deduplikaciu sam o sebe? Myslim, ze napr. BackupPC to vie. :)
    22.12.2012 15:30 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Hledám něco, co umí deduplikaci na úrovni bloků, BackupPC umí jen na úrovni souborů.
    Josef Kufner avatar 23.12.2012 16:34 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    A vadí, že by to bylo na úrovni souborů? Pokud záloha vypadá tak, že máš adresář, kde je nakopírovaný filesystem ze zálohovaného stroje, tak to bude v pohodě, ne?
    Hello world ! Segmentation fault (core dumped)
    27.12.2012 11:26 j
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Rek bych ze to vadi celkem zasadne, protoze to bude razantne vetsi. Zkus si predstavit, ze mas 2x 100GB databaze, ktera je z 99% totozna ... => budes tam mit 200GB nebo 101GB ... celkem rozdil, ze...
    Josef Kufner avatar 27.12.2012 11:47 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Pokud má tazatel takto velké a takto podobné soubory, tak pak jo. Otázkou je, zda takové soubory má a zda jich je dost na to, aby to vadilo. U pracovních stanic to prakticky nehrozí, u serverů zas je celkem malá šance na tak velikou podobnost.
    Hello world ! Segmentation fault (core dumped)
    27.12.2012 16:39 dustin | skóre: 61 | blog: dustin
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Pokud jsou ty databáze živé, tak stejně taková záloha s dost vysokou pravděpodobností nebude fungovat a to i přes filesystémový snapshot. DB bych zálohoval jejich nástroji, ne přes filesystém.

    Používáme již roky backuppc a jeho deduplikace je docela obstojná a spolehlivá. Momentálně máme zabráno cca 50 mil. inodů, soubory jsem nepočítal, odhaduji tak 5x více.

    Běží na XFS, 3GB RAM, pro xfs_check (/repair) to vyžaduje připojit do externí esata kolébky ssd disk jako swap, pak doběhne za pár hodin. Kolébky jsou tam stejně pro pravidlné kopírování na offline disky, takže jde o triviální úkon.

    22.12.2012 16:06 MilanK
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    ZFS je i na linuxu [1], byť se doporučuje pouze 64bitová architektura. Z dotazu není jasné, zda to pole je redundantní či nikoliv. (Případné snížení rizika při redundanci.)

    Paměťové nároky při deduplikaci souvisejí s velikostí bloku a lze je snad trochu snížit použitím L2ARC [2] na SSD. Ale stále to nepochybně bude velký "žrout". Paměťové nároky jsou dány zpracováním v režimu "pre-write dedup".

    Hash funkci u ZFS lze zvolit, standardně je tuším SHA256. Pokud ji nevěříte, umí pracovat v režimu zpětného ověřování dat už při zápisu a při kolizi to nějak vyřeší.

    [1] http://comments.gmane.org/gmane.linux.file-systems.zfs.user/2911 [2] http://mail.opensolaris.org/pipermail/zfs-discuss/2011-May/048171.html
    22.12.2012 17:16 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    To diskové pole je software raid 5. Server má k dispozici jen 5 GB RAM. Když jsem na svém PC zkoušel DDumbFS, tak pro 4 TB svazek o velikosti bloku 64k mi to zabralo něco přes 2,5 GB RAM. Kdybych se u ZFS vešel na 6 TB do cca 4 GB RAM, tak by nebylo co řešit. Ale podle toho, co jsem našel by bylo potřeba tak 36 GB RAM. Umožňuje ZFS zvolit minimální velikost bloku a zmenšit tak razantně paměťové nároky? Podle toho, co jsem našel má ZFS dynamickou velikost bloku ...
    22.12.2012 17:29 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Tak podle http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html jsem si spočítal, že i pro 128k bloky bych potřeboval 15 GB RAM.
    22.12.2012 18:34 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Napadlo mě dát DDumbFS přímo na diskový oddíl, takže DDumbFS by pod sebou neměl žádný fs. Potom ten fs připojit a v něm vytvořit přes dd soubor plný nul a na něm vytvořit btrfs nebo zfs. Takže by btrfs byl uvnitř toho deduplikovacího fs. Tak bych se totiž alespoň mohl dozvědět, jestli jsou data v pořádku (v případě hash kolize v DDumbFS). Je to hodně špatná myšlenka?
    22.12.2012 20:27 MIlanK
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    IMHO, DDumbFS je FUSE FS a vyžaduje pod sebou nějaký FS. Nenašel jsem, jaký má DDumbFS limit na velikost souboru.

    Máte tedy v plánu něco takového: nějaký sw raid + ext4 + DDumbFS + ZFS (s kontrolou dat, ale v neredundantním poli, takže bez možnosti obnovení).

    Nebo s omezením efektu deduplikace na část raidu:
    HDD1 s ext4 + DDumbFS + kontejner1 2 TB
    HDD2 s ext4 + DDumbFS + kontejner2 2 TB
    HDD3 s ext4 + DDumbFS + kontejner3 2 TB
    a poté
    ZFS raidz z kontejner1+2+3
    (tedy s redundancí a možností obnovení)

    Pokud to zkusíte, dejte vědět.
    22.12.2012 22:34 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému

    No tak jsem to vyzkoušel a je to nesmysl. Zkoušel jsem na tedy prozatím na kombinaci RAID5->EXT4->DDUMBFS->EXT4. Problém je ten, že pokud vytvořím souborový systém v DDumbFS stejně velký jako velikost DDumbFS, pak vlastně přicházím o výhodu deduplikace. Pokud ten souborový systém vytvořím větší než je velikost DDumbFS, pak sice výhodu deduplikace mám a funguje perfektně (paradoxně lépe než bez té další vrstvy FS), ale po zaplnění DDumbFS přejde Ext4 do read-only módu, protože ačkoliv si myslí, že má ještě nějaké volné místo, tak ve skutečnosti žádné není.

    ZFS také vzdávám, protože jsem našel nějaké testy a i při použití SSD jako mezicache je zápis či čtení mnohonásobně pomalejší než s 1 cache v RAM.

    Nakonec asi udělám to, že na raid 5 oddílu vytvořím btrfs a uvnitř DDumbFS, takže budu mít výhodu deduplikace v DDumbFS a snapshotů v btrfs. Jenom mi vadí ta pravděpodobnost hash kolize, i když je hrozně malá.

    Nikola Ciprich avatar 23.12.2012 16:22 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Bohumín
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Nakonec asi udělám to, že na raid 5 oddílu vytvořím btrfs a uvnitř DDumbFS, takže budu mít výhodu deduplikace v DDumbFS a snapshotů v btrfs. Jenom mi vadí ta pravděpodobnost hash kolize, i když je hrozně malá.
    neberte to jako rypani, ale nemuzu si pomoct - vy to mate na zalohovani nejakych serioznich dat, nebo jako hrani s daty na kterych Vam nezalezi??
    Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
    23.12.2012 16:42 freak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Pravdepodobnost bugu v celym tom bastlu vam jako vubec nevadi? Na data typu porno si radsi kupte dalsi disky..
    Nikola Ciprich avatar 23.12.2012 16:46 Nikola Ciprich | skóre: 23 | blog: NiX_blog | Bohumín
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    presne proto jsem se ptal jestli na tech datech vubec zalezi.. nejaky relativne novy projekt na deduplikaci nad fuse v kombinaci s FS ktery je stale oznacen jako experimental s moznou zmenou formatu, to mi prijde jako dobra ruleta..
    Did you ever touch the starlight ? Dream for a thousand years? Have you ever seen the beauty Of a newborn century?
    23.12.2012 23:28 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Samozřejmě, že mi na datech záleží. Problém je, že je jich moc, datové pole plné a nejsou finance na jeho rozšíření. Když jsem testoval deduplikaci na časti dat, tak deduplikovaná data zabrala místo 800 GB jen cca 250 GB, což už je obrovská úspora.
    24.12.2012 00:06 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    A místo btrfs vlastně můžu použít něco stabilního (ext4), protože snapshoty udělám jednoduše pomocí příkazu cp (mám přece deduplikaci, ne?).
    24.12.2012 00:07 linuxik | skóre: 32 | Milovice
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    HA HA HA, myslis to vazne?
    24.12.2012 01:53 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Proč ne? Nebudu samozřejmě kopírovat soubory v DDumbFS, ale v ddfsroot, kde jsou umístěny soubory ve tvaru |adresa|hash|adresa|hash..., takže 1 GB soubor vlastně na této úrovni zabírá 422 KB. Celý snapshot proces může sestávat z této jednoduché kopie, která bude trvat maximálně několik málo sekund. Má to nevýhodu v tom, že během kopírování se mohou původní data v souboru/souborech měnit, nicméně v tomto případě (backup úložiště) k tomu docházet nebude.
    23.12.2012 17:46 l4m4
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    nevýhody: pro detekci stejných bloků používá hashování
    A to je nevýhoda proč?

    Vy nečetli, a přesto rozmrazili? Samozřejmě, že kolize hashů je ošetřena, v technické dokumentaci se dokonce docela podrobně píše jak.
    23.12.2012 23:10 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Já jsem koukal do zdrojáků LessFS, DDumbFS i SDFS a nikde jsem neviděl, že by byla kolize ošetřena. To, co se píše na stránkách DDumbFS se podle mě týká umístění bloků v BlockFilu nežli hashů samotných bloků dat. Všechny tyto souborové systémy spoléhají jen na to, že možnost kolize je extrémně malá.
    23.12.2012 23:41 l4m4
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    OK, pokud jsi četl zdrojáky, tak počítám, že víš, jak je to doopravdy. Což je tedy smutné, čekal bych, že když matchne hash, tak se porovnávají data (nebo alespoň další hashe -- sníží-li se pravděpodobnost o dalších 2^{-128}, tak to už může primární i sekundární zálohovací místo taky současně vyhořet...).
    23.12.2012 23:59 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Oni takhle dokonce asi fungují i některá komerční řešení viz. http://www.backupcentral.com/wiki/index.php/Disk_Targets,_currently_shipping. Pravděpodobnost poškození dat chybou pamětí (i ECC pamětí), disků, řadičů, ... je mnohonásobně vyšší než pravděpodobnost kolize, proto na to asi výrobci kašlou.
    23.12.2012 23:54 linuxik | skóre: 32 | Milovice
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Ne ze bych nejak podcenoval bezpecnost ale pri pouziti SHA256 a dejme tomu pri 1 bilionu bloku v dedup filesystemu, je pravdepodobnost kolize 10 na minus 60. To drive skonci nas vesmir velkym krachem, nez se neco takoveho stane. Pouze v pripade ze plati teorie o tepelne smrti vesmiru by jsi mel sanci, pokud se driv nerozpadnou vsechny protony ;-)
    24.12.2012 00:03 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Na 64bitové architektuře všechny tyhle FS používají plný Tiger-192 hash, protože je podle všeho nějak akcelerovaný či co, ale i tak je ta pravděpodobnost velice malá. Hlavní problém může být v tom, že tohle je teoretická pravděpodobnost. Prakticky může být o dost vyšší (špatný návrh algoritmu, špatná implementace).
    24.12.2012 02:05 lertimir | skóre: 60 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Tedy mě to připadá jako blábol někoho, kdo není zvyklý počítat s velkými čísly. Jako když při spouštění LHC neznalci mluvili o zničení země černou dirou vyrobenou v tom CERNu O čem to mluvíte?

    Špatný návrh algoritmu? Tiger je z roku 1996, byl podroben už dost silné kryptoanalýze a jsou samozřejmě konstrukce kolizních útoků, ale ty jsou na redukovaný počet rund a není znám žádný útok snižující bezpečnost a odolnost proti kolizi pro plný Tiger.

    Špatná implementace? Tady je to citlivější téma, chybná implementace typicky vyrábí další informaci například v čase zpracování a pak je využití této informace cílem útoků tzv. postranními kanály. Ale Tiger je jednoduchý hash vlastního disku, buď na konci výpočtu máme cílovou a kontrolovatelnou hodnotu nebo ne.

    Navíc Vaše argumentace není o cíleném útoku, ale o náhodné kolizi. Máte přestavu jaké jsou to pravděpodobnosti?

    V roce 2010 před krizí byly čtvrtletní prodeje disků někde pod 170 miliony kusů tedy ročne 610mil cca 2^30 kusů, předpokládejme (nadsazenou) zivotnost disků 16 let. a předchozí prodeje ve stejné výši. tedy je v provozu 2^34 disků. Nechť všechny disky zapisují maximální rychlostí cca 256 MB/s to je 512 tisíc sektorů za vteřinu. tedy 2^19 sektorů. Dohromady všechny disky na planetě zapisují v této nadsazené úvaze 2^53 sektorů. Otázka je jak dlouho, by musely ty disky běžet, aby pravděpodobnost vygenerování stejného hashe byla větší než zadaná hodnota (limit). Stejný hash myslím mezi všemi možnými již dříve použitými hashi. Díky "narozenivému paradoxu" je to projítí 2^((192-ln2(limit))/2) možností, kde ln2 je dvojkový logaritmus čísla. pro např. pravděpodobnost 1 miliontinu to znamená 2^((192-20)/2) = 2^86, takže teprve za 2^(86-53)=2^33 sekund nastane situace, kdy pravděpodobnost, že za celou tu dobu ve dvou discích na celé planetě byly dva různé sektory se stejným hashem, přesáhla jednu miliontinu. A 2^33 sekund je něco přes 272 let. Nebo jinak, za dobu životnosti disků řekněme (16 let) se pravděpodobnost, že za celou dobu se vyskytly ve dvou sektorech všech disků planety v libovolném čase dva stejné hashe je pod 10^(-9).

    Kolize těch vašich několik TB opravdu neohrožuje.
    24.12.2012 00:23 l4m4
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Toto je argument, že slow path řešící kolize může být fakt very slow. Ale že by tam vůbec neměla být, tj. že i teoretický návrh může fungovat pouze pravděpodonostně... Chytnou-li se této myšlenky vývojáři software obecně, skončí to u programů, které budou fungovat ve čtyřech případech z pěti.
    Josef Kufner avatar 24.12.2012 00:35 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Ono to tak ale často opravdu je. Pokud je pravděpodobnost chyby dostatečně nízká a případné škody akceptovatelné, tak se na to prostě kašle, protože se to nevyplatí řešit. Spousty algoritmů jsou jen aproximace, které teoreticky nemusí nikdy doběhnout, ale většinou doběhnou výrazně dřív než jejich exaktní varianty.
    Hello world ! Segmentation fault (core dumped)
    24.12.2012 00:40 l4m4
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Jistě, ovšem když používám Marquardt-Levenbergův algoritmus k fitování, tak rozumím a akceptuji, že může dokonvergovat k ledasčemu. Není to ovšem vlastnost, kterou bych tak snadno akceptoval u zálohování...
    24.12.2012 00:44 linuxik | skóre: 32 | Milovice
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Prave naopak, pokud je pravdepodobnost selhani ostatnich komponent radove vyssi ( v tomto pripade minimalne o 40 radu) nema zadnou cenu resit hash kolize. Tim ze pridate do aplikace dalsi kod, ktery bude mit take nejakou pravdepodobnost vyskytu chyby, muzete ve skutecnosti problem jeste zhorsit. Chapu ze vyrobci enterprise reseni neco takoveho delaji, ale matemeticky je to nesmysl a slouzi pouze k uklidneni manageru, kteri neco o hash kolizi zaslechli.
    24.12.2012 03:22 FooBar
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Deduplikacni reseni jsou natolik niche market, ze bych se bal cokoliv nasazovat. Doporucil bych se spis snazit o file-level deduplikaci nebo provadet agresivnejsi kompresi (komprimujes vubec? kdy? jak?).

    Hodne mne desi ze chces nasadit deduplikaci po blocich, ale absolutne nezminujes ze bys mel jakykoliv data potvrzujici ze by to bylo o tolik lepsi nez deduplikace po souborech. To je hodne silny varovny znameni, ze sahas po okrajovejch resenich bez toho abys mel podlozeny ze je fakt potrebujes.

    Co se tyka ZFS a zrani RAM, to je naprosto ocekavatelny jak kvuli deduplikaci, tak i jen kvuli tomu ze jde o ZFS -- ZFS minimalne na FBSD implementaci z dostatku RAM hodne tezi.
    24.12.2012 03:41 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    V současné době používám kompresi (bzip2 většinou) a deduplikaci na úrovni souborů (hardlinky), nestačí to.
    24.12.2012 23:50 Milan Beneš | skóre: 17 | blog: Kraft_durch_Freude
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Ahoj, taky dost záleží na tom, jakej charakter mají data, která chceš deduplikovat. Nspříklad můžu říct, že na datech z webhostingu není ZFS deduplikace žádná sláva. Mám za to, že se vyplatí nasadit pouze u úložiště virtuálních strojů a dedup ratio by mělo být tak aspoň 10, aby se ospravedlnily nároky na paměť. Pokud mě paměť neklame, tak deduplikace jednoho bloku sežere v ARC nějakých 170 byte. Jinak teď zkouším ZFS on Linux proti jádru 3.7.1 a tváří se to moc hezky :-). Na produkční mašinu bych to ale dal jen tehdy, pokud bych měl dobré zálohování a nebyla to nějaká mission-critical aplikace.
    Heron avatar 25.12.2012 21:17 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Dokoupit paměť nasadit ZFS a užívat si dalších výhod ;-).

    Netuším, jaký je tam FS teď, ale i na ext3,4 se ti může stát, že neuděláš ani fsck (resp. ano, ale jen jeho extrémně pomalou variantu šetřící paměť). U XFS by ten check byl úplně nemožný. Na takhle velké pole té paměti musí být mnohem víc.
    Zdeněk Zámečník avatar 27.12.2012 12:24 Zdeněk Zámečník | skóre: 26
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    Řešil jsem stejnou otázku téměř dva roky, přičemž jsem zkoušel stejná řešení jako ty, ale nakonec jsem došel k tomu, že ani jeden z těchto projektů se pro zálohy nehodí. U každého jsem dokázal celkem snadno docílit pádu filesystému, resp. Fuse v různých distrech (Debian, CentOS a Ubuntu), přičemž jsem byl limitován 8GB RAM. Dlouho jsem tomu dával šanci a trápil se s tím, ale velké zálohy mnoha malých souborů (emaily) znamenaly těžko překonatelný problém.

    Dnes používám pro zálohy BTRFS se zapnutou kompresí a jsem spokojen. Úspora místa je obvykle menší než při deduplikaci, ale rychlost a spolehlivost je někde úplně jinde. Ano, připravil jsem se o několik desítek, možná stovek GB na 6TB poli, ale na druhou stranu jsem si ušetřil spoustu času a nervů s nekonzistentními anebo ještě hůře žádnými zálohami. Pokud zálohujete na nějaké ne příliš drahé disky, zvažte zda vám v dnešní době ta úspora místa za to stojí.
    Heron avatar 27.12.2012 12:35 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    K tomu bych ještě doplnil, že u BTRFS lze využít reflinků, tedy pokud se teď někde dělá deduplikace souborů pomocí hardlinků (což lze dělat pouze u souborů, které se nikdy měnit nebudou), tak u reflinků je možné se všemi soubory dále pracovat.
    28.12.2012 16:20 atrak
    Rozbalit Rozbalit vše Re: Výběr deduplikovacího souborového systému
    No já už jsem nasadil ddumbfs a funguje naprosto bez problému. Jediný zádrhel může být správně si vypočítat velikost filesystému: podkladový ext4 má nějaký "režijní" informace + samotné uložené soubory (jsou v nich adresy bloků) na podkladovém fs mají nějakou velikost. Zálohuju na to virtuální stroje + windows server (přes tu jejich zálohu + cobian). Deduplikovaná data zabírají 23% původní velikosti, což je obrovská úspora.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.