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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 2
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 19
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 768 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

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: 1298×
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: 66
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: 66
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: 60 | 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: 58 | 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: 66
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: 50 | 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: 50 | 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.