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 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Komunita

MojeFedora.cz informuje, že Fedora 27 dostane podporu pro AAC. Podpora multimediálních formátů je ve výchozí instalaci Fedory tradičně limitovaná kvůli softwarovým patentům, ale desktopový tým Red Hatu se ji i tak snaží v poslední době co nejvíce rozšířit. Už nějaký čas obsahuje kodeky pro MP3, H.264, AC3 a nyní byl přidán také kodek pro další velmi rozšířený zvukový formát – AAC.

Ladislav Hagara | Komentářů: 0
včera 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
včera 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
včera 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 4
včera 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 5
včera 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
včera 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 4
17.10. 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 11
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (11%)
 (1%)
 (1%)
 (1%)
 (74%)
 (13%)
Celkem 95 hlasů
 Komentářů: 5, poslední dnes 07:28
    Rozcestník

    Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    17.5.2014 13:45 | Přečteno: 4076× | Výběrový blog | poslední úprava: 17.5.2014 16:44

    Stará NASka praská ve švech. Disky v ní jsou téměř 5 let staré a jsou v RAID5. Hodně blbá kombinace. Navíc na začátku jsem učinil pár nepříliš šťastných rozhodnutí ohledně rozdělení, které mě nyní iritují. Část vyhrazená pro raw iSCSI je příliš malá takže se mezi ostatními daty válejí obří iSCSI soubory a podobně. Ostatně neznám nikoho, kdo měl v tomto směru dobrý odhad, pominu-li šťastlivce, kteří si můžou dovolit mít všechno na jednom svazku. Teoreticky by se daly udělat nějaké shrinky/expandy/přesuny... jenže mě se do experimentů na 7 TiB svazku, navíc z větší části nezálohovaném, příliš nechce.

    Zrodil se tedy projekt úložiště pro takové to malé, domácí ukládání v normální domácnosti. No... normální. Pouze pokud se tak dá nazvat dvoučlenná domácnost, kde router i v noci indikuje 25 statických IP adres a 12 přidělených přes DHCP.

    Požadavky

    1. Kapacita 14 TiB+. Současné úložiště má 7 TiB a princip zdvojnásobování kapacity každých 5 let se mi v minulosti osvědčil.
    2. Odolnost proti výpadku dvou disků.
    3. Nezávislost na hardwaru, zejména na hardwarových RAIDech (o pseudohardwarových raději ani nemluvě). Když zaklepe základní deska křemíkovými bačkorami, chci mít možnost přehodit disky do jiného počítače a jedním příkazem data připojit. Nechci shánět po všech čertech stejný řadič nebo laborovat jak jsou uložená metadata abych to nějak zprovoznil přes md.
    4. Chci online deduplikaci. Zálohuji ESXi virtuální stroje a deduplikace mi udělá transparentně a bezproblémově rozdílové zálohy. Je rozdíl skladovat 150 GiB záloh virtuálních mašin každý den nebo 150 MB rozdílových bloků.
    5. Chci snapshoty. Chci je levné a chci je rychlé i když jich bude hodně. A nechci předem vyhrazovat místo, které může snapshot zabrat. Chci snapshot pracovního adresáře každých 10 minut a chci je skladovat týden, 1000 snapshotů tedy nesmí činit potíže.
    6. Chci kontrolní součty dat. Kdybych nezažil silent data corruption (zapíšete A, přečtete B přičemž disk ani řadič nehlásí žádný problém), tak bych na tom třeba netrval. Ale zažil. Dvakrát. Jednou vinou řadiče, který prostě občas na disk poslal chybná data a jednou jsem viděl phantom read. Byl požadován sektor X a byl přečten a předán sektor Y. Nezjištěno, kdo za to mohl, asi SSD.
    7. Nechci už nikdy přenikdy řešit situaci, že tady je místa málo a tady zase zbytečně hodně a řešení sice existuje, je ale netriviální a trvá dlouho.
    8. Cena. Nechci zbytečně přeplácet, to je jasné.
    9. Ocenil bych, kdyby volume manager rozuměl datům na disku. Aby se třeba při rebuildu RAIDU na svazku zaplněném z 10 % řešilo jen těch 10 % a ne zbytečně i prázdné místo. To je výhoda z hlediska času ale i bezpečnosti dat. Vypadne disk z RAIDu, dáte nový, spustí se rebuild, který trvá půl dne, zvýšená zátěž na disky zvyšuje pravděpodobnost, že odejde další. A Murphyho zákony všichni známe. Opět jsem viděl na vlastní oči.
    10. Mohla by se hodit komprese. Zejména pokud by se dala aplikovat pouze na část disku.

    Výběr SW řešení

    1. md + nějaký souborový systém : splňuje 1, 2, 3, 8. 10 při použití souborového systému, který to umí. Populární NASky jako Synology nebo QNAP jsou na tom podobně jen je třeba vyhodit bod 8.
    2. HW raid + nějaký souborový systém nad tím: splňuje 1, 2. 10 při použití souborového systému, který to umí.
    3. LVM + nějaký souborový systém: splňuje 1, 2, 3, 5, 8. . 10 při použití souborového systému, který to umí. Bod 5 je teoreticky splněn ale kdo zkoušel v praxi více snapshotů, ten ví, že de facto není. Bod 7 také není uspokojivě vyřešen.
    4. BTRFS: plní 1, 2 (ovšem RAID6 nemá scrubbing), 4, 5 (ovšem jen out of the band- po zápisu je nutné spustit utilitku, která provede deduplikaci), 6, 7, 8, 9, 10
    5. ZFS: plní 1, 2, 3, 4, 5, 6, 7, 8 (s výhradami, vyžaduje SPOUSTU paměti), 9, 10

    Je vidět, že jasný vítěz zde sice není, nicméně použitelní kandidáti zůstali pouze 2. Je to věci osobní volby. BTRFS má navíc výhodu čistější licenci a je vyvíjeno přímo v jádře. ZFS mi zase přijde jako mnohem vyspělejší. A to nakonec převážilo a rozhodl jsem se pro tento systém.

    ZFS se dá použít v OpenIndiana nebo jiné variaci OpenSolarisu, FreeBSD nebo nějaké jeho nadstavbě (FreeNAS) ale také v Linuxu díky projektu http://zfsonlinux.org/. Rozhodl jsem se pro Linux, protože ho znám nejlépe.

    Výběr hardware

    Rozsah rešerše, které musí člověk podstoupit, když si chce koupit pitomý disk, je neuvěřitelný. Nebudu tím zatěžovat, vydalo by to na samostatný článek. Jako vítěz mi vyšel 3TB WD RED. Oproti třeba WD Green má trojnásobný MTBF. Je to sice číslo cucané z prstu ale při takovém rozdílu by to už něco mohlo znamenat. Navíc rozumí tomu, že poběží v RAIDu a že má tedy jen omezený čas na reakci. Některé disky se pokoušejí přečíst sektor třeba minutu. Řadič pak oprávněně označí celý takový disk jako vadný. Má nízkou spotřebu. Zkrátka z celého startovního pole těch levných šunkoidních disků mi vyšel nejlépe. 3TB varianta je (prý) méně poruchová než 4TB. Z požadované velikosti úložiště a kapacity disku a dvojité patity je zřejmé, že jsem musel pořídit 8 kusů.

    Ke koupi disků jedna poznámka- je lepší nakoupit disky z různých sérii. Minimalizuje se tím pravděpodobnost, že se do pole dostanou disky zatížené stejnou výrobní vadou.

    Základní desku je lepší koupit rovnou s potřebným počtem SATA portů. Rozšiřující karty jsou problematičtější a ve výsledku většinou i dražší. Je třeba si ověřit podporu řadiče. V případě Linuxu to většinou není problém, s FreeBSD to bývá horší a ESXi ve verzi 5.5 je vyloženě vybíravý a podporu pro většinu běžných řadičů nemá. Další důležitou vlastností je síťovka. Opět je lepší koupit rovnou vhodnou integrovanou kartu a nedokupovat pak zbytečně diskrétní síťovku protože ty bývají zbytečně drahé. Tady bych to charakterizoval takhle: Intel >>> Realtec > hromada hnoje > Broadcom. Pro ZFS potřebujeme hodně pamětí (odůvodnění bude v příští části, doporučuje se 1GiB paměti na 1TiB dat pokud nehodláte hojně použivat deduplikaci. V tom případě ještě mnohem více) a je tedy vhodné zakoupit desku s alespoň čtyřmi sloty. Paměť nejraději ECC. Když už máme checksumy v ZFS tak ať nám to nekazí chyby paměti. Procesor úsporný ale pro kompresi RAIDZ2 (což je ZFS název pro RAID6 s několika fíčurami navíc) to zase úplná plečka nemůže být. Výhodou je interní USB. Zbytek (jako integrovaná zvukovka, firewire a podobné blbosti) je nepodstatný. Já chtěl použit 2600K, který se mi válel v šuplíku spolu s 4x4GiB moduly. Tím jsem byl ve výběru desky značně omezen. Kvalitní desky dělá Supermicro. Já nakonec skončil s MSI Z77A-GD65. Je tam Intel síťovka, ASM1062 řadič pro dva dodatečné SATA porty, je tam tedy celkově 8 SATA portů, umí použít výstup "grafické karty" v procesoru což snižuje spotřebu a náklady na grafickou kartu. Současně to není deska tak úplně z "dolní poličky" takže má o něco málo kvalitnější součástky (s certifikací Military Class III ;-) :-p ).

    Nastavení BIOSu, příprava disků, rozchození ZFS v Linuxu, konfigurace... v příští části.

           

    Hodnocení: 100 %

            špatnédobré        

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

    Komentáře

    Vložit další komentář

    17.5.2014 14:44 victor8 | skóre: 24 | blog: blog | Košice
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Super, tesim sa na dalsiu cast, prave staviam nieco podobne (akurat mensie, len 9TB RAID6) nad Microserverom N40L, akurat som sa este nerozhodol ci ist do ZFS alebo ostat pri osvedcenej kombinacii devicemapperu + klasickeho linux fs.

    Nebojis sa stability ZFS nad linuxom? (predsalen je mimo kernelu)...
    17.5.2014 17:42 R
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Ja by som sa tiez bal pouzivat filesystem, ktory nie je sucastou jadra.
    17.5.2014 15:02 R
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Ten procesor nepodporuje ECC. Vid http://ark.intel.com/products/52214
    17.5.2014 15:19 typo
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    1)cte se to pekne blbe

    2)nikde nevidim zalozni zdroj

    3)chybi celkova cena a navratnost v porovnanim s nejakym cloudem
    17.5.2014 15:57 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Ta trojka je teda dost úlet - srovnávat koše s baňama.
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    Heron avatar 17.5.2014 17:19 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Dobrý článek, těším se na pokračování. U mě na 8TB úložiště loni vyhrál BTRFS, rád si přečtu o praktických zkušenostech s ZFS na Linuxu. (ZFS jsem zvažoval také, ale pouze na FreeBSD.)
    17.5.2014 17:55 Jerry
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Spravu o domaci sit mas s tim co popisujes zrejme na plny uvazek :) Kdyz budes silazovat pouze tva vlastni legalni "dulezita" data, tak by ti stacily 2x1TB disky v mirroru, nebo se mylim ? :)
    Max avatar 17.5.2014 18:52 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Jeden čas jsem měl pod křídlem cca 50 soukromých pc a nebylo to nic zabijáckého.
    Teď mám v jobu pod křídlem cca 300pc a je to relativně bez práce, na full time to rozhodně není a člověk má čas řešit servery, nové služby, apod.
    Zdar Max
    Měl jsem sen ... :(
    17.5.2014 19:17 Jerry
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Reagoval jsem na dvouclenou domacnost, temer 40 aktivnich IP adres, proste no comment :) Autor by se mel jeste zamyslet nad GEO NAS, nekdy staci malo, aby se nerozbitne reseni rozbilo :)
    Max avatar 17.5.2014 18:49 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Píšeš, že chceš ECC, ale vybereš CPU, co ECC neumí. Nevím, zda se něco změnilo, dlouho jsem na to nekoukal, ale dřív Intel na desktopu byl jasně bez šance na ECC, AMD na tom bylo mnohem líp.
    Jeden čas se houfně nakupoval "Intel Xeon E3-1230V2" a dával se do MSI desek - výkon jak i7, cena jak i5, možnost ECC a bez, pro většinu zbytečné, grafické části.
    Zdar Max
    Měl jsem sen ... :(
    Petr Tomášek avatar 17.5.2014 20:27 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Kde píše něco o ECC?

    IMHO tam píše o tom, že chce filesystem, co ukládá checksumy souborů (kryptografický hash a ne nějaké blbé crc)...
    17.5.2014 23:59 helb
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Paměť nejraději ECC. Když už máme checksumy v ZFS tak ať nám to nekazí chyby paměti.
    18.5.2014 09:32 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Pišu také, že jsem použil tento procesor z důvodu, že jsem ho už měl. Zkrátka ekonomické rozhodnutí. To nic nemění na faktu, že doporučuji ECC řešení.
    17.5.2014 23:04 Tom
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    no my meli smulu znamy koupil 3TB red a po sedmi mesicich NAS skolaboval na vadnem sektoru... ale je pravda ze RED je porad lepsi nez GREEN rada
    Dreit avatar 18.5.2014 09:27 Dreit | skóre: 15 | blog: Dreit a jeho dračí postřehy | Královehradecký kraj
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    Dodal bych, že Blue řada je na tom stejně jako Green

    Nope
    19.5.2014 11:52 Sten
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Vadném sektoru jednoho disku? To se stává všem výrobcům. Taky proto existuje RAID.
    17.5.2014 23:48 Bhua
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Mam 2600K v hlavni workstation, do NASu bych ho nedal, neni z nejuspornejsich. Asi neco na Atomu v mini-itx.
    Jezekus avatar 18.5.2014 00:58 Jezekus | skóre: 18 | blog: jezkova_nora
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    Moc pekne tesim se na pokracovani :-)

    Nejaky podobny servrik na domaci zvykani jsem resitl a nakonec jsem pouzi AsRock C2750D4I procesor je celkem schopny a usporny, ECC RAM, IPMI, sitovky Intel, jsem s tim zatim spokojen.

    18.5.2014 10:54 Ondra
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    autor se nikde nezminil, ze by mel penize na rozhazovani.
    Jezekus avatar 19.5.2014 12:21 Jezekus | skóre: 18 | blog: jezkova_nora
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    Ja zas nemel v supliku i5-2600K :-)

    18.5.2014 08:51 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Pouzivame ZoL in production, tak o nem trochu vim a muzu rict, ze kdyz si das pozor na par veci, bude bezet v pohode. Bohuzel BTRFS podle mne urovne ZFS nikdy nedosahne, uz jenom proto, ze btrfs je zas "po linuxovsku" ladeny na maly instance a vyvijeny na noteboocich, kdezto nad ZFS da actually provozovat (a spravovat) server (ne orezavatko).
    Rovnou muzes sahnout po nejakem stabilnim distru (= se ZFS nechces bezet na vzdy nejnovejsi vanille) a aktualnim git HEAD ZFS a SPL, release 0.6.2 je strasne starej a zabugovanej.
    Kdyby tenhle portal za neco jeste stal, i bych se tu na blogu rozepsal, protoze se ZoL mam opravdu dost zkusenosti, o ktere stoji se podelit... Jenom musi byt s kym (mistni banda zarucene kazi chut sem cokoliv inteligentnejsiho psat...)
    --- vpsFree.cz --- Virtuální servery svobodně
    18.5.2014 10:23 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Jinak off-top-of-my-head muzu rict, ze pokud nad tim chces bezet iSCSI, musis prijit na to, jak na iSCSI initiatoru vynutit sector size stejny, jako je block size ZVOL na targetu, jinak zacnes delat read-modify-write misto jenom write pro prepsani bloku (iSCSI standardne pouziva sector size 512B a to je problem, ZVOLy jsou efektivni az tak od 8k block size).
    Dal se urcite vyplati limitovat ARC size (nejlepsi zacit od malych hodnot a propracovat se nahoru, kam az to zveda hitrate), zapnout kompresi, nepouzivat deduplikaci, nastavit zfs_txg_timeout na vic jak 5s (jinak zbytecne syncuje) a pokud mozno nikdy neobsazovat vic jak cca 75% mista (je to copy-on-write FS a tak je potreba se k tomu tak chovat).
    Kdyby nahodou aktualni ZoL git head nesel pouzit, tu https://github.com/vpsfreecz jsou nase forky, ktere mame in production a jsou overene (aspon s RHEL6/OpenVZ kernelem).
    --- vpsFree.cz --- Virtuální servery svobodně
    18.5.2014 10:42 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Ctu ten tvuj zapisek jeste jednou, jak pises "chci deduplikaci", tak to mozna jeste nevis, ale nechces, za zadnou cenu. Teda pokud tim nechces deduplikovat jenom pa GB, ale chces tim i efektivne neco prohnat. Dedup je pametove rozezrana neefektivni blbost, to je spis v kategorii "udelali jsme, protoze to jde", ne proto, ze by to melo uzitecnost (az na nekolik use-casu, ktery tvuj ale neni).
    Naopak kompresi nemas duvod nepouzivat na vsechno, je rychla (obzvlast lzjb) - ze ji ani nepoznas, na disk se komprimovane ukladaji jenom data, u kterych se zjisti dobry kompresni pomer, nekomprimuji se nuly a tak ... neni to tupa komprese, ale je to navrzene proto, aby se to dalo pouzivat. V praxi u vpsFree to znamena, ze minimalne na zalohovacim poli nam komprese kompenzuje kapacitni ztratu za RAID-Z (tzn. kompresni pomer aspon 1.3 a lepsi).
    --- vpsFree.cz --- Virtuální servery svobodně
    18.5.2014 11:19 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Díky za rady a doporučení. Myslím, že zálohy ESXi jsou právě pro deduplikaci docela vhodným kandidátem. Denní zálohy mají 150 GiB ale mají od předchozí zálohy jen málo změn (desítky MiB). Zatím jsem nezjistil, zda s tím nemíchá komprese. Dedup ratio se zda se nedá zjistit pro datastore ale jen pro celý pool takže konkrétní číslo nemám. Teoreticky by mohla být úspora až 1:1000.

    Samozřejmě si jsem vědom, že je třeba hlídat velikost DDT. Je škoda, že ten poměr nejde nastavit lépe, já vlastně ARC jako cache dat nepotřebuji protože víc, než dá to pole i bez cache stejně ven přes gigabit nedostanu.

    18.5.2014 11:26 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    No ne, ta dedup je fakt spatna vec, myslim, ze na to budes akorat nadavat... Ale teda kdyz uz, tak mej potom aspon 1 GB RAM na kazdej TB na poolu se zapnutym dedupem. Nicmene pro to, co rikas, se hodi mnohem vic vykoumat, jak pri zalohovani toho esxi to donutit nemenit bloky, co se shodujou s puvodnima. O tom nemam ani paru, vmware neznam.
    --- vpsFree.cz --- Virtuální servery svobodně
    18.5.2014 15:52 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Zjistil jsem, že při kopírování dat do datasetů, které nemají zapnutý dedup velikost DDT neroste (a není tedy pravda co se občas píše, že se deduplikuje vůči celému poolu ale jen vůči datasetům s dedupem) takže by to nemělo být tak kritické. 1 GiB na 1 TiB mám tak jako tak. Pool ma něco přes 16 TiB a paměti mám 16 GiB. V případě krize rozšířitelné na 32 GiB. Je ovšem fakt, že by to stálo tolik jako rozdíl mezi 3TB a 4TB disky, měl bych ~6 TB místa navíc a nemusel bych asi řešit dedup ;-)
    18.5.2014 12:51 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    A co se tyce REDu, co mam zkusenost, jsou asi levne proto, ze nejsou moc testovane. Jelikoz z cca 50ti nam 3 (z jinych varek) odesly do tydne/dvou, ale ostatni zatim drzi, bych rekl, ze se asi pocita s tim, ze si jich clovek koupi vic a kdyz to odchazi, tak se k tomu chova jako ke spotrebnimu zbozi, tzn. jde to do kose (reklamace tak levneho disku se nemusi vyplatit ani zakaznikovi, natoz dodavateli).
    --- vpsFree.cz --- Virtuální servery svobodně
    Josef Kufner avatar 18.5.2014 13:43 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Nebylo by lepší to nechat nekomprimované, aby byla deduplikace efektivnější?
    Hello world ! Segmentation fault (core dumped)
    18.5.2014 14:06 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Jestli se blok deduplikuje komprimovany nebo ne je uplne jedno, rozhoduje chcecksum dat. Jediny usecase, kde nema smysl kompresi zapinat, jsou medialni soubory a obecne spatne komprimovatelna data, u nich se stejne vetsinou ulozi puvodni nekomprimovana verze, protoze pomer vyjde spatne.
    --- vpsFree.cz --- Virtuální servery svobodně
    Josef Kufner avatar 18.5.2014 22:55 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Otázkou však je, zda po změně jednoho bloku nedojde ke změně i následujícího bloku. Například kvůli tomu, že se nová data povedlo lépe zkomprimovat a zbytek souboru se posune.
    Hello world ! Segmentation fault (core dumped)
    19.5.2014 11:00 Chulda | skóre: 19
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    A dává smysl zálohovat celá VM? Není rozumnější párkrát měsíčně/ročně zazálohovat VM a důležitá data přes nějaký backup?

    V tu chvíli denní zálohy budou mít pár GB a částečnou deduplikaci může dělat backup (rozdílová záloha)
    19.5.2014 12:16 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Ono je rozdíl jestli odzálohuješ minimální potřebnou Linux instalaci, kde má třeba full (tar.bz2) záloha < 400MiB a denní přírustek pár mega (bez dat), takže třeba v měsíčním cyklu si na hodnotě třeba 500/600MiB vs. odzálohovat jakékoliv Widle, kde ti na to nestačí ani 10× více.
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    19.5.2014 16:03 Chulda | skóre: 19
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Toho jsem si vědom, proto jsem to napsal jako dotaz, nikoli kategorické tvrzení. A ani widle obvykle není třeba zálohovat celé.
    19.5.2014 18:13 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Přijde na to, jak dlouho má trvat a jak komplikovaná má být obnova, někdy se vyplatí zálohovat i /var/tmp.
    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    19.5.2014 16:51 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    V mé situaci, kdy mám virtuály na 5 různých OSech, nad některých nemám a nechci mít roota je odpověď myslím jasná.

    Zálohování uvnitř bych řešil dny. Při každé změně bych musel pořád něco řešit. A pak by se ukázalo, že jsem něco zapomněl zálohovat. Nebo že se něco nezálohovalo kvůli právům nebo nějaké jiné záležitosti, zkrátka bych to musel pořád kontrolovat. Přídání každého VM by mě stálo zase práci.

    Rozchození zálohy celých VM bylo oproti tomu otázkou deseti minut (nakopírovat ghetto do ESXi, změnit pár věci v konfiguraci a hodit do cronu). Přidání dalšího VM mě stojí přesně 0 vteřin.
    19.5.2014 18:40 Šangala | skóre: 56 | blog: Dutá Vrba - Wally
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    Předem: nemám nic proti zálohování celých mašina a asi máš k tomu důvody, ale pár poznámek k některým větám :)…

    V mé situaci, kdy mám virtuály na 5 různých OSech, nad některých nemám a nechci mít roota je odpověď myslím jasná.
    Je pravda že ESXi jen z povzdáli můžu sledovat a nijak se nezajímám, ale pokud bych vzal paralelu s KVM s hosty na LVM (a nectěl bych to dělat jako push zevnitř), tak stačí udělal snapshot „z venku“ připojit read only a od zálohovat libovolnou metodou (tar cjf .... -g ...).
    Platí za předpokladu, že se nešifruje VM až uvnitř - jinak je třeba znát ještě passhrazi.

    Zálohování uvnitř bych řešil dny. Při každé změně bych musel pořád něco řešit. A pak by se ukázalo, že jsem něco zapomněl zálohovat. Nebo že se něco nezálohovalo kvůli právům nebo nějaké jiné záležitosti, zkrátka bych to musel pořád kontrolovat. Přídání každého VM by mě stálo zase práci.
    Viz výše a znamenalo by to jen, přidání do nějakého seznamu.
    NEBO
    Universální zálohovací skript v každém stroji (jak jsou to Widle, tak to lze taky přes Cygwin, ale ty pak po obnově stejně nenastartují :( ), spouštěný cron-em, kdo má root-a má plné odpovědnost když to vypne, nicméně to lze z venku kontrolovat (třeba jen velikostí záloh), navíc může být záloha šifrovaná a to klíčem známým jen správci daného stroje, takže si ze zálohami může „hospodařit“ i cizí osoba a daný správce si může kdykoliv cokoliv vyhledat. (Kdo má nešifrované zálohy má všechno co potřeboval ;-))

    Rozchození zálohy celých VM bylo oproti tomu otázkou deseti minut (nakopírovat ghetto do ESXi, změnit pár věci v konfiguraci a hodit do cronu). Přidání dalšího VM mě stojí přesně 0 vteřin.
    Je možné že je to nejrychlejší řešeni pro nasazení, ale dost nepříjemné s ohledem na velikost ukládaných dat (nejhorší by asi bylo prosté dd). Přidání dalšího stroje v případě Linuxu by mohlo být pod 1 min pokud není součásti template (vložit skript).

    PS: Pokud těch 5 OS zahrnuje Widle a není to jedna/dvě mašiny, tak chápu, že je to tak na jistotu, ale toho místa je mi líto :-)

    To, že trpíš stihomamem, ještě neznamená, že po tobě nejdou. ⰞⰏⰉⰓⰀⰜⰉ ⰗⰞⰅⰜⰘ ⰈⰅⰏⰉ ⰒⰑⰎⰉⰁⰕⰅ ⰏⰉ ⰒⰓⰄⰅⰎ ·:⁖⁘⁙†
    Josef Kufner avatar 20.5.2014 11:29 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    V okamžiku, kdy se to podělá, je mnohem rychlejší a jistější obnovit celý systém, jak byl. Dávat dokupy server z nějakých kousků je zdlouhavé a náchylné na chyby.
    Hello world ! Segmentation fault (core dumped)
    21.5.2014 17:50 Chulda | skóre: 19
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Není to tak jednoznačné, např. backup VM s TB diskem trvá hodiny, zatímco backup diff dat trvá desítky minut (změny max do celkové velikosti v řádu desítek GB).

    V případě velkých změn u velkého VM během dlouhé doby zálohování je ještě problém se zrušením snapshotu - opět bude trvat hodiny a také snížený výkon storage.

    Těch omezení je spousta a tak opravdu není jen jedna univerzální a vždy vhodná záloha.

    A ani ta jistota není jednoznačná. Snapshot neřeší neuložená aplikační data v RAM.

    Vše je to ale o požadavcích. Často je ale opravdu lepší čistý VM + dohrát data.
    21.5.2014 18:13 sigma
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    No, u lepších řešení lze dělat i inkrementální zálohy VM disků, a zrušení snapshotu rozhodně nemusí trvat hodiny. Tady se zásadně projevují rozdíly mezi snapshoty typu linuxového LVM, a COW přístup např. u ZFS. Ty inkrementální binární zálohy si můžete představit třeba jako ZFS snapsnoty a zfs send. U větších řešení je tohle řešeno na SAN úrovni.

    Co se týče konzistence dat v RAM, tak 1) je to stejné, jako kdyby ten stroj spadnul, a měl přitom zálohovanou writeback cache = co prošlo před fysnc(), to je bezpečně uloženo - tj. aplikace by s tím neměly mít úplně zásadní problém; a 2) pro samotné aplikace může být nějaký agent, který jim dá vědět, aby udělaly checkpoint. Nevím, jak v linuxu, ale na Windows Server je tohle integrální součást systému/NTFS, se kterou řada aplikací umí pracovat (MSSQL Server, Exchange).

    Ano, vše je o požadavcích, ale v situaci, kdy virtualizační systém a guesty spravují jiní lidé je výrazně praktičtější umět VM obnovit bez další práce uvnitř ní. A jak už bylo řečeno, čím jednodušší postup v krizové situaci, tím větší šance, že to vyjde a bude to rychle hotové.
    22.5.2014 10:16 Chulda | skóre: 19
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    Jenže lepší řešení nejsou zdarma a pochybuji, že by si je kvůli své malé virtualizaci pořídil.
    Smazání snapshotu skrz vmware trvá dlouho.
    Na SAN úrovni máte zas problém, že se zálohuje všechno nebo nic, což ne vždy může vyhovovat a SAN neví nic o VM nebo aplikačních datech v RAM.

    ad 1) ale měl jsem za to, že se tomu se lidi snaží předejít. A v případě backup klienta tomu lze předejít.
    ad 2) jo VSS. Vmware to umí s windows OS (quiesce guest FS). Vtipný je, že i když s tím linux nepracuje, tak kernel v RHEL6 měl bug, kvůli kterému ten linux někdy vytuh.

    Ale na druhou stranu práce uvnitř ní už není starost provozovatele virtualizace. A pokud ti admini za něco stojí, tak stejně zálohují. Pak je IMHO lepší se s nimi domluvit, zda vůbec potřebujou častou zálohu celého VM.
    23.5.2014 14:40 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    To vše záleží na situaci - rychlost zálohy jak je vytížený diskový subsystém, rušení snapshotu je zase ovlivněno kolik tam nateklo během života snapshotu dat.

    Pokud můžu extrapolovat situaci u mě, tak záloha 1 TB VM bude trvat skutečně hodiny, konkrétně dvě hodiny a deset minut. A zrušení snapshotu (jelikož se to děje v noci) netvá dle logu esxi ani vteřinu takže nejsem schopen ani extrapolovat ;-)
    18.5.2014 23:45 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Kdyby tenhle portal za neco jeste stal, i bych se tu na blogu rozepsal, protoze se ZoL mam opravdu dost zkusenosti, o ktere stoji se podelit... Jenom musi byt s kym (mistni banda zarucene kazi chut sem cokoliv inteligentnejsiho psat...)

    Možná ti to ušlo, ale autor tohohle blogu, se kterým sis vyměnil bezmála deset příspěvků, je taky součástí místní bandy...
    Quando omni flunkus moritati
    19.5.2014 09:15 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Autora, narozdil od tebe a podobnych, co do te "bandy" radim, nevidim psat prispevky, ktere maji nulovou hodnotu, krom toho ukazat, jak to nekomu umis nandat. A ted se muzes chytit za nos :) Nicmene bych preferoval, kdyz uz, diskuzi k veci.
    --- vpsFree.cz --- Virtuální servery svobodně
    19.5.2014 10:03 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    krom toho ukazat, jak to nekomu umis nandat.
    Vidíš, co chceš vidět.
    Quando omni flunkus moritati
    18.5.2014 10:01 radeczek | skóre: 7
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Tohle vypadá na parádní zápisky... Už se těším na další díl.., Docela by měl pak zajímala celková cena, spotřeba, funkčnost. Snad se o tom s námi podělíš. Nějaké fotky budou?
    the.max avatar 18.5.2014 19:16 the.max | skóre: 46 | blog: Davidovo smetiště | Bílina
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Tak držím palce, aby ti ty 3TB disky vydrželi alespoň do konce záruky obzvlášť při 24/7 a nestane se ti to samé co mě, kdy jsem tři a půl roku zpět kupoval v jednom nejmenovaném velkoobchodě 2 constellationy es s 60ti měsíčni zárukou. Dodáky se bohužel při stěhování ztratili a když teď ty disky odešli a při vyhledání záruky ve velkoobchodě je najednou ze 60ti měsíců pouze 36 a dodáky pro jistotu zobrazit nejdou vůbec. Disky odešli 3 měsíce po 'novém' konci zaáruky. A nikde se ničeho nedovolám.
    KERNEL ULTRAS Fan Team || Sabaton - nejlepší učitel dějepisu || Gentoo - dokud nás systemd nerozdělí.
    18.5.2014 19:49 R
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Chod na web Seagate, tam je niekde zahrabana moznost zistenia zaruky podla serioveho cisla disku. Ak tam zistis, ze zaruka je platna, daju sa disky poslat postou priamo do Seagate (to musis zaplatit ty) a oni ti poslu nove (resp. opravene).
    the.max avatar 18.5.2014 21:04 the.max | skóre: 46 | blog: Davidovo smetiště | Bílina
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Dík, našel, In Warranty Expiration 12-Oct-2015
    KERNEL ULTRAS Fan Team || Sabaton - nejlepší učitel dějepisu || Gentoo - dokud nás systemd nerozdělí.
    18.5.2014 23:43 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Kašli na to, jestli ti pošlou "opravené" disky, z poštovného budou akorát vyhozené peníze.
    Quando omni flunkus moritati
    Max avatar 19.5.2014 07:05 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Proč? Já takto úspěšně reklamoval a spokojenost.
    Zdar Max
    Měl jsem sen ... :(
    19.5.2014 09:07 xm | skóre: 36 | blog: Osvobozený blog | Praha
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Už jsem od vícero lidí slyšel, že Seagate posílá opravené (refurbished) disky, které velmi brzo odchází. Takže dát si něco na takový disk, co přijde zpátky ze Seagate, je o hubu (teda pokud člověk poctivě zálohuje tak o hubu ne, ale i tak ;-)).
    Svoboda je tím nejdůležitějším, co máme. Nenechte se o ní připravit, podporujte Pirátskou stranu!
    19.5.2014 10:05 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Přesně tak, co si pamatuju, tak žádný z těch "opravených" disků nevydržel dýl než pár měsíců.
    Quando omni flunkus moritati
    19.5.2014 21:14 R
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Jeden sa mi akurat dnes vysral :( Teda on funguje, lenze rychlostou asi 130KB/s...
    19.5.2014 21:21 R
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Dat si nieco na lubovolny disk bez zalohy je o hubu. Novy disk moze odist uplne rovnako.

    Minule som menil v notebooku disk (tiez Seagate), ktory mal len asi 1000 hodin nabehanych a bol uplne v prdeli. Padom to nebolo - notebook bol neposkodeny, ako novy a navyse mal ochranu disku pri pade. Nejake data som zachranil, ale mnohe subory uz nesli precitat. Po par hodinach sa z disku uz nedalo precitat nic, ani MBR.
    19.5.2014 11:02 alkoholik | skóre: 35 | blog: Alkoholik
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    ERC/TLER si muzes nastavit na co chces..
    smartctl -l scterc,50,50 /dev/sda
    19.5.2014 23:03 PanZvedavy
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    Zajimave, autor se snazi na jednu stranu vybrat co nejspolehlivejsi reseni pro sva data v podobe ZFS, coz je opravdu dobra volba(ne-li dnes nejlepsi mozna), aby pozadovanou spolehlivost hned v zapeti poslal do kopru ignorovanim tak zakladni veci u ZFS jako je potreba ecc ram. U FS ktery je v podstate cely o ram je to pomerne nestastna volba. Staci procist par manualu k ZFS od sun-oracle nebo treba tady http://zfsonlinux.org/faq.html#DoIHaveToUseECCMemory.

    Dalsi dulezitou komponentou je cpu...neni moc vhodne zvolit orezane polodpady jako atom ci jine low-watt srandicky. Naopak je potreba zvolit silne cpu, staci spustit na poolu scrub a i 4xcore na 3GHz se zacne poradne potit. Nekde jsem cetl, ze sun doporucoval minimalne dvoujadro. Intel core 2600 je vykonove hodne slusne, bohuzel neumi ecc.

    Co se tyce volby OS, tak pro co nejstabilnejsi provoz ZFS se voli bud samotnej solaris(jehoz ultimativne-zasadni vyhodou dneska je nativni podpora sifrovani) nebo a je nejcastejsi volbou v komunitach "domacich kutilu" - openindiana ci BSD. BSD ma jednu zasadni vyhodu oproti openindiana a to, ze neni tak vybiravy po HW strance a je preci jen bliz svetu linuxu co se prace s nim tyce. Linuxu bych se v pripade ZFS vyhnul, ale padnej-zasadni argument nedodam-nemam, jen neznam nikoho, kdo by ZFS provozoval v realu na linuxu, coz neznamena, ze to nemuze nekde stabilne nejak jet :).
    Zkratka dlouhodobe jsou v pripade ZFS nejpouzivanejsi a nejspolehlivejsi BSD s openindianou, ale kdyz to autor zkusi na linuxu jeho volba a sam jsem zvedavej.

    20.5.2014 09:11 xm | skóre: 36 | blog: Osvobozený blog | Praha
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Přijde mi, že jste úplně mimo. Ne každý má stejné požadavky a myslím si, že ty autora blogpostu se hodně liší od toho co si představujete vy. Ostatně i ve vámi odkazovaném FAQu o ECC pamětech se píše:
    For home users the additional safety brought by ECC memory might not justify the cost. It's up to you to determine what level of protection your data requires.
    Svoboda je tím nejdůležitějším, co máme. Nenechte se o ní připravit, podporujte Pirátskou stranu!
    20.5.2014 11:25 R
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Videl som aj ext3 kvalitne rozosraty od vadnej RAM. Pri molochu typu ZFS si viem predstavit, ze to potom nikto neda dokopy.
    20.5.2014 19:40 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Co konkretne je na ZFS molochovity, kdyz se bavime o ondisk formatu? Ten je prave uplne jednoduchej a jasnej... ZFS se muze zdat komplexni, protoze integruje hodne puvodne nesouvisejicich konceptu dohromady, ale uvnitr ma celkem primocary navrh a ten kod se velmi dobre cte.
    --- vpsFree.cz --- Virtuální servery svobodně
    20.5.2014 21:55 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Dokonce, kdyz tak nad tim premejslim, se ZFS bys to daval dohromady mnohem jednodusejc, protoze rovnou vis, jestli blok, kterej z disku vytahujes, je ok nebo ne, navic se bavime o copy on write FS, coz na ty obnovitelnosti docela pridava. A diky transakcnimu navrhu pripadne neni az takovej problem ziskat stav toho FS aspon z jedny recent transaction groupy. Aneb co neznam, toho se bojim :-)
    --- vpsFree.cz --- Virtuální servery svobodně
    21.5.2014 10:11 PanZvedavy
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.

    I lowend hw raid radice pouzivaji ecc ram. Dovolite si vymenit ecc ramku na raid radici(za predpokladu ze to firmware radice dovoli, coz nedovoli) za klasickou ramku, ktera se prodava za par svestek(128MB-1G)?
    A ted kdyz to prevedem na ZFS, ktery bude pouzivat X ram modulu osazenych na zakladni desce, tak se moznost chyb kazdym dalsim modulem nasobi.

    Je to jako jezdit v zime na letnich sjetych pneumatikach. I kdyby to bylo po 95-99 procent casu bez problemu a ridic mel stesti, tak prave to jedno procento dela a meni vse a v ten moment se ukaze sila zimnich gum - ecc ram. Je to samospasitelne? Samozrejme, ze ne, ale kdo jednou zazije ledovku na galuskacich, kde muze jit o hodne, tak si da sakra majzla na "pozadavky".
    Pokud tvrdite, ze jsem "úplně mimo" predpokladam, ze mate nemale zkusenosti s provozem ZFS na klasickych ram bez ecc a na tom zakladate sva tvrzeni...nikoliv na linku s "might not justify the cost".

    David Watzke avatar 7.6.2014 13:47 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Projekt: domácí datové úložiště (ZFS, 16 TiB), část 1.
    Jako vítěz mi vyšel 3TB WD RED. Oproti třeba WD Green má trojnásobný MTBF.
    Hmm, ty jsem měl v sw raid1 a chcíply mi oba téměř ve stejnou dobu :-) Jen tak tak jsem to stihnul odkopírovat.
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon

    Založit nové vláknoNahoru

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