Šoupání s daty

29.1.2012 18:16 | Přečteno: 2154× | Za vším hledej Linux | poslední úprava: 2.2.2012 14:01

Už několikátý den rošáduji s disky, a tak si říkám, že by možná neuškodilo podělit se s oním martyriem, aby si i ti co dosud objem dat na disku počítají na gigabajty, mohli představit, že to je většinou především hrozná otrava a čekání.

Scelování dat a nasazení raid 1

Na samém počátku byl proces scelování dat rozházených po všech čertech a discích. Když jsem se dohrabal k utěšeným 1,8TB tak jsem si řekl že to už by mě opravdu sakra mrzelo, kdybych o ta data přišel a tak jsem pořídil 2x1TB Seagate, vytvořil na něm linuxový sw raid 1, a LVM logický oddíl naformátoval na btrfs. Postupně jsem pak do něj začal všechna data přesypávat. Z rachoty jsem si půjčil 1TB disk, odsypal na něj zbylá data a z uvolněných disků poskládal další pole, přes které se pak ten logický disk roztáhnul.

Plán na vytvoření pole raid 6

Začal jsem sice klidněji spát, nicméně cca 200GB volného místa není nic moc. Proto jsem začal pokukovat po větších discích. Jenže koupit najednou 2x2TB se SATA III, byla přeci jenom pálka. A proč kupovat disky se SATA II, když deska i řadiče podporují rychlejší přístup, že? A tak jsem pokukoval jak ceny zvolna padají.

Aby však byla přeci jenom nějaká rezerva, půjčil jsem si dva rezervní 2TB disky ze sady pro plánované úložiště - jak se ukázalo, zahoření nebylo od věci, protože jeden ze sady těcho disků se záhy ukázal zralý na reklamaci - mimochodem zatím druhý Seagate v mém životě, na kterém se objevily nějaké chyby. (První byl 750GB SATA II).

Zakoupení disků

Jenže pak to vypláchlo fabriky v Thajsku a ceny vyletěly vzhůru jak poplašený vrabec. Takže jsem s koupí musel počkat. Nicméně přišel čas, kdy už to nešlo déle odkládat. Disky, které jsem zatím využíval budou potřeba jinde, disky s kapacitou větší jak 3TB jsou zatím v nedohlednu a tak jsem se odhodlal ke koupi 4x2TB se SATA III s cílem sestavit z nich linuxové sw raid 6 pole a všechny pomalejší disky vyházet - přesněji řečeno použít tam, kde se uplatní.

Volba raid6 není náhodná. Čas od času se stane, že se uvolní v kompu nějaký konektor a pokud běží nad tím polem LVM skupina, tak by bylo velmi nemilé, kdyby jí najednou upadly dva disky - jak na potvoru - ze stejného pole. To už mi tedy přijde rozumnější obětovat část prostoru pro uložení dalších metadat.

Problém byl, že jsem nemohl koupit všechny čtyři disky najednou. Přeci jenom - 3,5 tis. za jeden disk je pořád pálka. V první várce jsem tedy koupil 2x2TB (á 3,5 tis.) + 1x60GB SSD (2,7 tis), s cílem na SSD umístit systém a uživatelské adresáře - v těch totiž nic důležitého není. Podstatné adresáře jsou nabindované z úložiště.

Protože jsem ale nechtěl riskovat případnou ztrátu, tak jsem ty dva disky zatím nepoužil na sestavení degradovaného pole s raid 6 ale vytvořil opět raid 1. Na ten jsem v rychlosti přešoupnul všechny data z disků, které bylo potřeba vrátit.

O týden později jsem koupil stejný typ 2xTB, ovšem od jiné firmy, takže mě vyšly ještě s nějakými konektory "jen" 7,5 tis. Při jejich testu se ukázalo že mají novější firmware, než ty co jsem koupil dříve, takže jsem je přemlasknul na CC4C (z CC47), doma opět vytvořil raid 1 a s jeho pomocí pak scelil 2TB fragmentovaného LVM logického oddílu. K té fragmentaci došlo především kvůli tomu, že jsem se při předchozí operaci nechtěl zdržovat. Krom se mi nechtělo riskovat upgrade firmware na discích s nezálohovanými daty.

Aktualizoval jsem tedy i tyto dva disky - tentokrát z verze CC46 na CC4C a konečně mohl přistoupit k vytvoření kýženého raid6 pole. Na pomoc při kopírování jsem si zapůjčil opět 2x2TB z práce a šel na věc.

Vzhůru do neznáma

No jo, jenže jaké zvolit pro raid6 optimální nastavení? Z nejrůznějších testů na internetu někomu vycházely lepší testy při chunku 64, jinému při 256, no zkrátka - chaos. Navíc nikdo se nezaobíral specifiky pole typu raid6 na tak velkých discích. Zkusil jsem tedy vytvořit ze 3 disků degradované pole typu raid6 s velikostí chunku 64. Přesun 2TB extentů z pole raid 1 na tento degradovaný raid 6 (3 disky) trval téměř 24hodin. Po přesunu se však ukázalo, že se všechny extenty při téhle velikosti chunku nevejdou. Chunků o velikosti 64 je prostě moc a příslušná metadata zaberou více místa.

Rozhodnul jsem se tedy vytvořit z uvolněných disků nové pole s velikostí chunku 2048. Nad ním pak novou LVM skupinu a logický disk s aktuální verzí btrfs. A pak data přesunout na úrovni souborového systému. Nové pole však muselo zůstat degradované na pouhé 2 disky. Ne že bych neměl ještě jeden 2TB disk v záloze, ale už zkrátka nebylo kam ho připojit.

Teprve dodatečně jsem narazil na blogpost, který se vlivem velikosti chunku na výkon raidu rovněž zaobíral. Podle jeho testů se zdá, že čím větší velikost chunku, tím větší je rozdíl mezi rychlostí čtení a zápisu. Chunk o velikosti 64 je tedy optimální pro toho, kdo potřebuje minimální disproporci mezi rychlostí čtení a zápisu.

Moje úložiště však je víceméně statický archiv, takže chunky o velikosti 2048 nebyly zase tak úplně špatná volba. I když defaultní velikost chunku (512) by zřejmě vyhovovala lépe. Aktuální rychlost zápisu 28MB/s u btrfs, které pro všechny datové bloky dělá kontrolní součty a také je komprimuje, mi nepřijde zase tak úplně děsná. A jak se zdá, měla by být vykompenzována rychlejším načítáním obsahu.

Na jak dlouho vystačí?

Jak známo - čím větší diskový prostor k dispozici, tím rychleji se zaplní. Musím však říct, že v poslední době už množství dat které skladuji moc neroste. Je to dáno tím, že už jsou všechna data na jedné hromadě a je tak mnohem snazší v nich dělat pořádek. V minulosti se mi nastřádalo v nejrůznějších zálohách mraky duplicitních souborů. Ty postupně odstraňuji. Nové soubory se tak ukládají místo nich.

Jak se zdá, chvíli potrvá, než se objeví disky s kapacitou nad 3TB, a z hlediska bezpečnosti uložení dat mi přijde řešení které jsem zvolil, nejoptimálnější. Je sice pravda, že SSD disky pravděpodobně cenově rotační disky zanedlouho doženou, ovšem od stávající ceny 80 litrů za 1TB je k tomu ještě docela daleko. A nasadit SSD disk bez raidu bych si tuplem nelajznul.

Poučení z krizového vývoje

Takže pokud rovněž plánujete vytvořit podobné úložiště, pokusím se zmínit o chybách, kterými jsem zbytečně ztratil čas:

• Pokud je to jen trochu možné, tak disky na nichž probíhají přesuny či synchronizace raidového pole, nepoužívejte.
• Počítejte s tím, že paralelní práce s disky takové operace značně zpomalí. Při přesunu LVM extentů je celková doba přesunu zhruba dvoj až trojnásobně delší. Na druhou stranu, i když pak trvá přesun příšerně dlouho, lze diskový prostor normálně používat.
• Data začněte kopírovat na pole až je plně synchronizované. Pokud není pole synchronizované, a potřebujete data přesunout co nejrychleji, tak přidejte chybějící disky raději až po překopírování dat. Kdybyste je přidali hned, tak synchronizace pojede brutálně pomalu a navíc její režie výrazně zpomalí rychlost kopírování.
• Synchronizace pole, na které průběžně neprobíhají žádné větší zápisy, proběhne poměrně rychle zhruba za 6-7 hodin. Což je zhruba stejná doba jako u 2TB pole raid 1 na SATA II.

Update

Jak se zdá, martyrium je konečně u konce, takže mohu dodat i nějaká orientační data.

Pole je složeno ze 4x2TB SATA III disků Seagate ST2000DM001-9YN164 s firmware aktualizovaným na CC4C. Co si poněkud nedokážu vysvětlit, jsou rychlosti zápisu které udává hdparm. U disků koupených z Alzy je to cca 170MB/s a u disků z lan-shop.cz je to kolem 140MB/s. Přitom typ i firmware disků je stejný. Zkoušel jsem pro zajímavost přehodit i porty na řadiči. Výsledek je stejný.

Velikost raid 6 pole s chunky o velikosti 64 byla 3,2TB. Pole s chunky o velikosti 2048 má 3,7TB. Obsazeno daty je celkem 2,9TB.

Rychlost synchronizace zmiňuji na naší manuálové stránce k RAID zařízením, pro ty co to tam nechtějí hledat jenom uvedu že, počáteční synchronizace ze dvou disků na tři trvala 13 hodin. A ze tří na čtyři pak dalších 17 hodin. To jsem měl ovšem v tom raidu i jeden disk SATA II. Po jeho nahrazení trvala stejná operace pouze 6 hodin. Podotýkám, že mám všechna disková zařízení připojená přes SATA III.

Rychlosti čtení a zápisu výsledného pole odpovídají - z hlediska poměru - údajům naměřeným v referenčním testu. V konkrétních číslech: Zápis probíhá průměrně rychlostí 46MB/s a rychlost čtení kolísá od 130 do 150 MB/s. Souborový systém pole je Btrfs. Zkusmo jsem kopíroval virtuální disk o velikosti cca 9GB. Druhý disk je SSD formátovaný na ext4. Ta neprovádí kompresi, takže se dá říct že rychlost čtení (i zápisu) odpovídá reálnému toku dat. Relativně nízká hodnota pro zápis je u btrfs zkreslena tím, že na rozdíl od ext4 btrfs na pozadí data komprimuje a provádí automatickou defragmentaci.

       

Komentáře

[Mrkva]

tak jsem si řekl že to už by mě opravdu sakra mrzelo, kdybych o ta data přišel

...

a LVM logický oddíl naformátoval na btrfs

Ehm...

[Aleš Kapica]

V tom blogu jsem neuvedl časovou osu - nepovažoval jsem to za nutné, ale btrfs používám už třetím rokem bez nejmenšího problému. A osobně se domnívám že pro účely datové storage je to to z linuxových souborových systémů ten nejlepší co se dá použít.

Ještě jednou opakuji - datové storage. Btrfs se totiž svou podstatou nehodí jako podkladový souborový systém pro virtuály. U těch není komprese datových bloků žádoucí, takže tam používám ext4. Koneckonců - u těchto strojů se o data stará vnitřní souborový systém.

Stejně tak se nehodí - tedy přesněji řečeno se nehodil - Btrfs na systémový disk. A to z toho důvodu, že nebylo možné na něj aplikovat fsck. To však již neplatí.

Nad LVM oddílem je Btrfs naprosto v pohodě, protože dovoluje bez problémů měnit velikost všemi směry - prakticky odzkoušeno. A jeho vlastnosti ocení obzvláště ten kdo používá takhle velké diskové oddíly.

[Mrkva]

Já jen, že v jádře není oflagovaný jako EXPERIMENTAL jen tak z legrace. Nebo je?

[Aleš Kapica]

To určitě ne. Ale když se to porovná s ext4, tak ač experimentální fs, se mi jeví dlouhodobě jistější. A ten pocit je založený především na jeho praktickém použití.

[Trained.Monkey]

Proste to vis lip nez jeho autori

Sam pisu DB (podobne fs), ale svoje data bych ji nesveril minimalne dalsich nekolik let.

[Aleš Kapica]

1. Kdyby nebyl btrfs použitelný, tak by nebyl v jádře
2. To jestli je nějaký FS součástí kernelu a zda-li je označený jako EXPERIMENTAL, nebo ne, není pouze otázka jeho kvality a spolehlivosti, ale především politika. Viz Reiser4, který jsem používal ještě před btrfs
3. Pokud máš argumenty, které by dokládaly opak, tak sem s nimi
4. Pokud píšeš DB, které nevěříš natolik abys jí svěřil svá data, tak to není moc dobrá vizitka pro tvou práci.

[kotyz]

To tam bude minimálně do tý doby než pro něj bude funkční fsck. Na mě je btrfs moc inovativní a novej, tak sem radši přemigroval z ext3 na ext4, ale až tak o rok nebo dva pozdějš než ostatní. Pořád sem s tim váhal a nechtělo se mi do toho. Teď se mi zas pár let nebude chtít to migrovat na něco jinýho.

[Heron]

Mě na tom více zaujalo to BTRFS nad LVM. Btrfs má vlastní multi device manager.

I když z tohoto:

tak jsem si řekl že to už by mě opravdu sakra mrzelo, kdybych o ta data přišel

asi plyne, že Aleš ta data nezálohuje. Asi je nepotřebuje.

[Aleš Kapica]

Docela by mě zajímalo jak by sis představoval zálohování takového kvanta dat. Já došel k tomu co mám evolucí. Uvažoval jsem i o použití zálohování na blue-ray disky - jenže na takovou diskotéku nemám čas. Ta data jsou totiž stále živá. V tom smyslu, že je přehazuji, přejmenovávám, třídím, upravuji. Ovšem pouze když se na to najde chvilka. A nepředpokládám, že bych s tím byl někdy hotov.

LVM pod Btrfs mi dává větší flexibilitu a kontrolu nad tím co kam je připojeno. A taky to více odpovídá filosofii původního unixu. Je sice fajn, že bych mohl sestavit raid přímo v Btrfs. Jenže to samé bych mohl i přímo v LVM, a přesto to nedělám. To raději oželím část výkonu.

Důvod? Firmware disku, SW raid, i btrfs, mají své opravné mechanismy. U každé vrstvy se může vyskytnout chyba a čím je jich více, tím je její výskyt pravděpodobnější. Ovšem na druhou stranu je o to nižší pravděpodobnost, že se ty chyby sejdou současně na jednom místě.

[Heron]

Docela by mě zajímalo jak by sis představoval zálohování takového kvanta dat.

Já mám v kompech dohromady asi 5TB diskového prostoru, kde je asi 3.5TB dat, a protože o ta data opravdu nechci přijít, tak k tomu asi 4.5 TB externích disků pro zálohy. Zálohování však nemám automatizované. Zkrátka kdykoliv mám pocit, že jsem od minulé zálohy udělal nějakou důležitou změnu (jednou, dvakrát do měsíce), tak to nasypu na externí disky. V případě, že komp lehne popelem, tak nepřijdu o všechno. Mít všechny disky neustále online, to bych byl hodně nervozní.

[Aleš Kapica]

To je domácí komp. Tam ty disky nejsou pořád on-line.

[Heron]

No ale ten komp je jedinné fyzické umístění těch dat, ne? Když to celý chcípne (neštastně umře zdroj a vezme s sebou i disky), tak jsou data fuč.

[Aleš Kapica]

Zažil jsem už leccos, i mí kolegové, ale o tom že by zdroj sebou sebral i disky jsem pouze slyšel. Po pravdě řečeno mi to přijde méně pravděpodobné, než to že bychom (opět) vyhořeli - a v takové situaci už by mi to bylo asi srdečně jedno. Na to abych udržoval paralelní zálohu mimo bydliště fakt nemám. Čas, infrastrukturu ani prostředky.

Mimochodem to je jeden z důvodů proč jsem přesvědčen o prospěšnosti sdílení filmů, knih a audio souborů. Bohužel spousta zajímavých věcí je už pravděpodobně po povodních v r. 2004 nenávratně ztracena. Kdyby existovaly elektronické kopie, které by bylo možné volně sdílet, tak by se bezpochyby pro řadu z nich našli lidé, ochotní věnovat svůj diskový prostor pro uložení jejich lokální kopie.

[Aleš Kapica]

A že časem pořídím i nějaký zálohovací NAS jsem nijak nevyloučil. Momentálně takto funguje právě zmíněný stroj, kam čas od času přesouvám data která jsou na noteboocích. Objemná data, která jsou určená pouze pro občasné použití - jako audio a video soubory, se na nich pouští skrz NFS.

Původní záměr - totiž aby to jelo jako server pořád jsem vyloučil z důvodu spotřeby. I když je proti obvyklému průměru extrémně nízká, stále je to hodně. Navíc žena i babička jsou děsně nervózní z modré kontrolky na desce. Svítí hodně intenzivně a tak mají pocit že to žere mnohem víc než odpovídá realitě. Jinak před výpadkem napětí a proudovými nárazy ho chrání UPS s přepěťovkou.

[Gilhad]

Co takhle HW řešení human problému - kontrolku zatemnit ať už odporem, nebo sklíčkem, nebo prostě fixou? Nebude svítit tak intenzivně a spotřeba rázem klesne na akceptovatelnou úroveň.

(Stejně jako mě skorotchyně chválila za pomalou a opatrnou jízdu, protože jsem měl zařazený vyšší stupeň a motor tak jel tišeji v nižších otáčkách, ačkoli auto se pohybovalo podstatně rychleji než referenční vůz :) )

[Trained.Monkey]

Ty se bojis ztraty dat a pouzivas Btrfs? Hm...

Vsude pouzivam Ext4, par partition pro Vmware ma Ext2. Moje konfigurace disku:

1) 64 GB SSD s roof a home. Home je kryptovany pomoci Ecryptfs z Ubuntu, dost to zjednodusuje organizaci dat. Na tomhle disku mam "svoje zivobyti" je to asi 40GB.

2) 1TB rychly disk pro ruzna data, fotky, hudbu apod. Vsechno je pomoci symlinku z home transparente integrovane. Tady jsou data pro ktera si trhat zily nebudu ale zalezi, asi 600 GB.

3) Nzkootackovy 2 TB disku na filmy a zalohy. Partition se zalohami neni obvykle mountnuta.

Raidu moc nemusim, prijde mi moc slozity na konfiguraci a udrzbu. Navic potrebuju spise neco obnovit z historie, nez mit aktualni system.

Data z 1) maji rsync kazdou hodinu na 2) a 3). Nechavam si poslednich 48 zaloh (dva dny).

Data z 1) a 2) kazdou pulnoc rsyncuju na 3). Tady nechavam 60 zaloh (2 mesice).

Data z 1) a cast 2) kazdy tyden zalohuju na prenosny USB disk. Po zbytek tydne je disk dobre schovany.

Pokud potrebuju delat na notebooku nebo obnovuju zalohu, tak proste zkopiruju data, upravim grub a jedu.

[Gilhad]

ext4 taky umí dělat podivuhodné věci se soubory (hlavně přičarovat délku 0), nebo alespoň nedávno umělo, dle jaderných novin. Na vině byly prý aplikace, které se k tomu chovali jako k ext2/3 a spoléhaly na něco, co norma nevyžadovala a ext4 tudíž nedělalo. Jasně že chyba je v těch aplikacích, ale když jsou data v čudu, tak to nepotěší, ať už je přímý viník kdokoli. (A možná tam jde něco zapnout, aby se to "chovalo postaru, jak aplikace mylně očekávají", už si nevzpomínám)

[kotyz]

To už je asi dva roky vyřešený (nebo spíš obejitý) a defaultně je ext4 nastavený tak aby se tomu předcházelo (chová se jako ext3 v ordered mode).

[Aleš Kapica]

No. Nejsem si tak zcela jist. Systémový SSD disk je na ext4 a už mě opět vypekl. Soubory z otazníčkama místo práv jsem už dlouho neviděl. U kompu bez možnosti nabootovat odjinud docela prekérka.

Jinak btrfs používám na data s nimiž se moc nešoupe - tam se mi to osvědčilo. Na systém obvykle používám léty prověřený a osvědčený reiserfs. Teď jsem však učinil výjimku - kvůli SSD disku, kterému způsob jak pracuje reiserfs příliš nesvědčí.

[Gilhad]

Taky mám v dlouhodobém plánu udělat centrální zálohu a pořádek. Až jednou bude čas a nálada. Zatím jsem vymyslel pár triků, které by se mohly (a nemusely) hodit:

• nechat si sjet obsah disku pomocí md5sum do (mega)souboru (a mít pak možnost si ověřit, že se nic neztratilo/nepoškodilo - máloco naštve víc, než když člověk zjistí, že má soubor zálohovaný na deseti místech, ale všude už je verze s chybou)
• tento soubor seřadit dle hashe a najít tak snadno duplicity obsahu (nikoli jména) - například pic12345.jpg = pic12345-rybnik.2011.zari.jpg = 2011.09.dovolena.rybnik.jpg
• nacpat to do databáze kde jako jeden z indexů bude ten hash. Kromě jiných skopičin bude snadné u nového souboru spočíst md5 a vyhledat v databázi, zda ho už nemám
• protože md5 mám i na archivních CD/DVD, tak budu schopen v databázi dohledat snadno, o co vše jsem přišel kvůli nečitelným mediím a tudíž bych měl zkusit najít jinde (když jsem to z jednoho CD nepřečetl a z jiného přečetl, nemusím to hledat, už to mám - čili pouze seznam nečitelných nestačí)

Určitě se najdou i další využití, časem ...

[Aleš Kapica]

Tohle jsem dělal právě v té fázi sjednocování. Udělal jsem si na to skript. Každý z disků jsem zkopíroval do jednoho adresáře a pak jsem si sjel ty kontrolní součty. Ten skript je pak porovnával.

U souborů, které měly shodný kontrolní součet ponechal v jednom exempláři ty co byly na důveryhodnějším svazku a ty co se lišily ponechal. Zredukoval to na nějakých 30GB, a když mám čas, tak se tím probírám. Díky tomu že to mám v jednom prostoru mi nové duplicity tak často nevznikají a objeví se jenom sem tam. Když na nějakou přijdu tak soubor smáznu a je hned o chlup více místa.

[D-Evil]

Pokud máte svoje data hodně rád, doporučil bych ještě v případě shody md5 hashů provést i skutečně porování souborů. Shoda md5 hashů neznamená nutně shodu dat. Běžně toto dělají např. virtualizační nástroje při deduplikaci RAM, protože tam může každá chyba hodně bolet.

[JS]

To "doporucil bych" znamena "setkal jsem se s tim v praxi" nebo "uveril jsem nejakym reklamam o tom, ze je to k necemu"? I kdyz ja bych misto MD5 pouzival SHA1, a databazovy system, ktery to dela (a castecne ho popsal Gilhad vyse) to taky tak ma.

[Gilhad]

Pokud dva soubory mají stejnou délku, měly by podle jména mít stejný obsah a md5 sedí, tak celkem věřím, že sedí i ten obsah. Dvě vzájemně různé verze obrázku se stejnou md5 jsem zatím buď nepotkal, nebo nerozpoznal.

[j]

Ze by nahodne vznikl soubor se stejnym MD5 ale jinym obsahem je situace nikoli nerealna, ale pocitam ze tech nul za nulou a carkou v procentech bude hodne moc ... Predpokladam, ze pravdepodobnost uspesneho teleportu osoby z mista A na msto B je vyssi.

[JoHnY2]

A pokud by mel clovek spatnej pocit, tak pri dnesnich vykonech vetsinou neni problem sahnout po SHA-256 kde je sance kolize "kapku" mensi.

[Heron]

nechat si sjet obsah disku pomocí md5sum do (mega)souboru (a mít pak možnost si ověřit, že se nic neztratilo/nepoškodilo - máloco naštve víc, než když člověk zjistí, že má soubor zálohovaný na deseti místech, ale všude už je verze s chybou)

Možná by bylo lepší nechat md5 konečně v klidu umřít. Používám SHA512.

nacpat to do databáze kde jako jeden z indexů bude ten hash. Kromě jiných skopičin bude snadné u nového souboru spočíst md5 a vyhledat v databázi, zda ho už nemám

Já jsem dřív přemýšlel (potom jsem objevil squashfs a ještě potom btrfs) o ukládání dat (nejenom nějakého seznamu) do DB a jejich deduplikaci (dle bloků, nikoliv celých souborů). Ale než se z myšlenky stal návrh, tak už tu jsou FS, které to umí / budou umět.

tento soubor seřadit dle hashe a najít tak snadno duplicity obsahu (nikoli jména) - například pic12345.jpg = pic12345-rybnik.2011.zari.jpg = 2011.09.dovolena.rybnik.jpg

fdupes; hardlink

[Gilhad]

mě se ještě nechce, některá data sahají do doby RedHat 6.1 a občas vylezou z nečekaných koutů.

fdupes jsem neznal - taky používá md5 - a když já už ty md5 mám, tak to vyhledání je celkem snadné. Navíc ne vždy to jde jen bezhlavě smazat či nahradit hardlinkem - některé vývojové větve i nesouvisejících projektů ptřeba občas obsahují dočasně stejný kód, který se rozdělí až později (typicky u mě různé konfiguráky) - smazání znefunkční větev, hardlink rozhodí druhou/třetí/další větev při změně.

[Heron]

Navíc ne vždy to jde jen bezhlavě smazat či nahradit hardlinkem - některé vývojové větve i nesouvisejících projektů ptřeba občas obsahují dočasně stejný kód, který se rozdělí až později (typicky u mě různé konfiguráky) - smazání znefunkční větev, hardlink rozhodí druhou/třetí/další větev při změně.

Jo jo. Na tohle se lépe než hardlinky hodí reflinky.

[gtz]

Aleši, 3GB disky jsou již běžně k dispozici, mělo by se jednat o model ST33000651AS. Ale cena 5800,- za kus je něco strašného. Ale je to pouze model pro desktopy, tedy nic pro servery. Ona by měla stačit i R5 s jedním spare diskek. U R6 je výhoda, že mohou vypadnout dva disky, ale když vypadnou tak pole je pomalé jako prase a resynchronizace je celkem hustá. No a R5 s spare je o něco rychlejší. Když jsem toto dělal tak jsem na toto používal výhradně XFS systém.

[Aleš Kapica]

To já vím, že jsou k dispozici. Nicméně jsem spokojen s tím co jsem koupil - SEAGATE Barracuda 7200.12 2000GB s Advanced Format. Pole z 3TB disků se cenově nevyplatí. Ten datový nárůst nestojí za řeč v poměru k tomu kolik bych za něj zaplatil.

Předpokládám, že s tímhle polem vystačím tak dva až tři roky. Jako zálohu - kdyby bylo akutně třeba více místa mám ty dva starší pomalejší 1TB disky. Složil bych z nich zase raid 1.

Podle toho co jsem zachytil za zprávy, tak se disky s 5TB připravují do výroby. A za tu dobu by snad už mohly být i v rozumné cenové relaci. Něco jiného než SATA III stejně hned tak asi nebude a v kompu bude po stěhování místo pro další 4 disky - zatím mi na tom visí ty disky ze kterých se to přesouvá a které půjdou pryč. Celkem je teď zapojených 10 disků. Pak za běžného provozu jich bude jen 5 (4x2TB rot. + 1x60GB SSD)

Do raid5 bych nešel. Bůhví co bude za ty dva tři roky. Ty laciné disky mají větší pravděpodobnost výskytu chyby. Toť vše. Nelze předem říct, které z nich se vysypou dřív. Takhle mám ale možnost ustát i dva chcíplé disky a připravit se mezi tím na podobnou investici jako teď.

[Aleš Kapica]

Ten stroj co mám doma jsem poskládal za nějakých 18 tisíc. Velké datové úložiště je v něm proto, že ho mám mimo jiné v plánu používat jako základ pro knižní skener - po elektronické stránce již všechno mám, včetně synchronizované spouště. Stroj má mimo jiné dvě TV karty s analogovým vstupem pro obraz s foťáků - kvůli ostření. Deska s AM3 má již SATA III a USB 3.0 V té ceně stroje jsou započítané i dva SATA III řadiče (každý se dvěma porty). Stroj je velmi tichý i když pochopitelně když se na ten zvuk člověk soustředí, tak slyšet je. Nicméně čerpadlo v akvárku je mnohem hlučnější. I s monitorem to má spotřebu 100W (se šesti disky) - měřil jsem to. Stavěl jsem to před rokem.

S těmi novými disky se cena vyšplhala cca na dvojnásobek, ale kapacita je větší a měla by být vyšší i rychlost, neboť už je všechno na SATA III. Musím ale ještě přeházet kabely. Teď jak jsem to zapojoval tak narychlo mám dva nové disky na jednom z těch řadičů a ten tak má poloviční přenosovou rychlost.

Není však vyloučeno, že to v budoucnu sakumprásk nahradí nějaký NAS, který vykopnu na balkón.

[gtz]

Použil bych klidně i R5 s disky pro raid (RE od WD nejsou špatné, ale já preferuji ST)

[Aleš Kapica]

Jinak jak to je pomalé, když vypadnou dva disky vím teď. Kopíruji na ně data O to víc se těším, až to dojede a já budu moci uvolnit dvě pozice, abych mohl ten raid doplnit na plný počet disků.

[gtz]

Jenže bacha, když máte pole v degrade modu pak stačí chybka někde na káblíku apod. a pole je rozesyncované a dávat to pak dohromady je někdy problém. Ideální je jak jsem psal, nechat resyncout pole na R5 v plné palbě, pak jej zatížit a pak teprve kopírovat ostrá data. (dělám nějakou dobu od 2003 disková pole, storage, FC apod.) a vím dobře jaká jsou úskalí a kde jsou ostatní hrdla. Pomalé to je a bude i tak (budeš muset dopllnit jeden disk+ celé to syncnout a to stejné u druhé disku a v tu dobu se může stát, že někde něco).

Ale ceny jsou brutus, nedávno jsem dodával pole v 2U,Xeonem, 12GB RAM, 12x 1TB za cca 2500€. Dneska ta samá konfigurace stojí od 3990€. Na soho dodávám malé domácí pole pro 5-7 disků taky s Linuxem a cena pro Tower s Areca R6 + 7x 1TB disků cca 1600€

Držím palec aby to bylo jak má být.

[Aleš Kapica]

Zrovna jsem ti chtěl napsat - nemaluj čerty na zeď a už tam byl kernel panic.. 8-)

Inu, zbrklost se nevyplácí - přendal jsem z toho degradovaného pole s 64 chunky ten třetí disk a přendal ho do toho co se na něj kopírovalo jenže tomu to neudělalo moc dobře, tak jsem ho zase vyndal. Ale asi mu něco popletlo hlavu.

Takže jsem teď zvolil menší zlo, sebral disk z 500G raid 1 - ten to snad přežije, než se to dokopíruje. Přinejhorším kdyby se podělal, tak ho obnovím z toho vyškubnutého. A místo něj zapojil ten záložní 2TB disk, ať jsou ty disky v obou polích alespoň tři. Holt musím s přehozením počkat až se to dokopíruje. Zítra na to bude mít celý den.

[gtz]

dělám ty pole nějakou dobu a když něco píšu tak vím co se může stát. Jak jsem psal nechat syncnout prázdné pole a pak teprve copy.

[Aleš Kapica]

Taky to tak dělávám. Ovšem občas pod tlakem udělá člověk různé blbiny. Obzvláště na vlastních datech. Naštěstí (ťuky ťuk) se mi ale už dlouho nestalo, že bych někdy udělal tak fatální botu, že bych o nějaká data nenávratně přišel.

O svá nejstarší data z doby, kdy jsem ještě nevlastnil PC ani notebook (1994/96) jsem přišel, když jsem je bláhově svěřil do úschovy na disk kámošovi. Jenže ten na to po čase jaksi pozapoměl, adresář mu nic neříkal a tak mi všechno smáznul. Takže mi zůstalo jen to, co jsem měl vytištěné.

Mě se později rovněž podařila podobná bota. Odzálohoval jsem data z notebooku na CD. Kouknul se zdali tam všechno je, namátkou zkusil jeden dva soubory - vše ok. Takže jsem s klidnou duší disk přeformátoval a (Windows 98 se) přeinstaloval. Večer pak dorazil kolega, že prý tam měl rozdělanou diplomku. Vytáhnem zálohu... ..a nic. Na CD byla jen struktura adresářů a pár souborů. Zbytek dat nikde. Jak na potvoru jsem se při zkoušení, trefil na soubory, co byly ok. Od té doby jsem k formátování a mazání souborů poněkud zdrženlivější a i to je důvod, proč se toho nahromadilo tolik. Na CD či DVD také není zrovna spolehnutí a na uchovávání dat, s nimiž se pracuje se moc nehodí.

[gtz]

jenže poslední dobou jsou disky nějak moc divoké (prostě to nejsou ty staré Seagate gumáky co vydržely hodně). Novější disky v rámci miniaturizace jsou celkem hodně očesané a snad jen SAS/FC disky tímto netrpí. CD/DVD nějakou dobu vydrží, ale nedávno jsem potřeboval přečíst jedno CD z roku tuším 1994 a měl jsem problémy. Nakonec jsem snížil rychlost na 1x a čekal jsem a čekal jsem. Jak říká jeden můj známý, raději to mám 2x než abych o něco přišel.

Kdysi jsem zkoušel v rychlosti poskládat pole, nechal jsem to synchronizovat a začal kopírovat data z druhého vadného pole. Když tam byla půlka tak si disk cvaknul a bylo to. Jako nic mu nebylo, prostě Molex. Dlouhá práce pryč, tak se muselo začít znovu, a musel jsem dávat hodně bacha na to staré pole, které jelo v degradu (R5) s jedním padlým diskem.

[the.max]

zish, k cemu takova diskova kapacita? Vzdyt porno neni nutny stahovat do pocitace, denne se objevuje na netu nove a nove

[D-Evil]

Ale samo se nestáhne

[Gilhad]

Jen počkej až přijde ACTA, budeš rád i za nalezenou disketu :)

[Aleš Kapica]

Kristepane. Shlédnout takovou dávku porna, tak mě vezou do cvokárny.

Mám tam všechny data, které se mi nasbíraly za posledních 15 let.

[Aleš Kapica]

S tím, že je tam hodně dat, které čekají na zpracování, "až se někdy najde čas" No a to jsou ty data, které průběžně nahrazuji.

[Walkeer]

Vsechny dostupne benchmarky se shoduji v tom, ze realne zrychleni SATA III oproti SATA II je maximalne v radu procent. Je to logicke, jelikoz maximalni prenosove rychlosti dosahovane 7200r disky jsou cca 170Mb, coz rozhodne neni strop SATA II, ktera ho ma na cca 270MBps. Vase zjisteni, ze se doba po vyhozeni SATA II disky zkratila na polovinu je silne zavadejici a v zadnem pripadne nemuze souviset s pouzitym radicem, je to zrejme spise vlasnot onoho starsiho disku.

[Aleš Kapica]

Jo, to máte bezpochyby pravdu. Jenom pro upřesnění udávám že šlo o disk (ST32000542AS s firmware CC34), který má jenom 5900 otáček a "Sustained data transfer rate" 95Mb/s, kdežto pro ty nové disky Seagate udává 210Mb/s.

Faktem však je, že Seagate takhle velké disky na SATA II s větším počtem otáček snad ani nedělal. Takže platí co jsem uvedl v blogu - nevyplatí se sestavovat takhle velké pole jako mix SATA II a SATA III disků.

Na desce mám pouze SATA III porty, takže nemohu dost dobře srovnat, jak by si co do rychlosti tohle pole vedlo na řadiči SATA II.