Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
A jak je tomu u Seagatu ST8000AS0002, který SMR též používá a je běžně dostupný?
u něj dochází ke zmíněným propadům ve výkonu
http://www.storagereview.com/seagate_archive_hdd_review_8tb
-------------------- -------------------- -------------------- -------------------- --------------------
Obavam sa ze on to myslel tak, ze ci aj sindlove 8 TB Morske Vrata potrebuju super-hyper-mega-ultra-brutal specialny soft/ovladac/aplikacie aby normalne fungoval, alebo si to riadi firmware sam, t.j. zapojim, o nic sa nestaram, ani len netusim ze mam sindlovy HDD a relativne normalne fungujem (samozrejme pokial tam hadzem 10 GB MKVcka, nie pokial tam instalujem OS).
Okrem toho 8 TB Morske Vrata su len sindlove a nie aj heliove - pokial sa nemylim. Tym padom so vzduchom byto malo byt "len" 5 platni (nie 7 ci 8 platni s heliom) po 1,6 TB.
-------------------- -------------------- -------------------- -------------------- --------------------
Takže cena za obrovskou kapacitu je výkonová nestálost, resp. degradace, pokud člověk nejede na Linuxu. Hmmm. Tak disk si jistě své uživatele najde, bežný uživatel to pravda nebude...
Možná do nějakého domácího NAS serveru, kde beží Linux, kterému se dá updatnout zkompilované jádro...? Nebo by to byla jen moc velké rozežranost na doma, aby si člověk mohl říci - jo, mám 10TB disk, to nemá jen tak někdo?
To sou dneska lidi, výrobci harddisků investují miliardy $$$ do vývoje technologie umožňující zvýšit kapacitu harddisků, po 10 letech vývoje to konečně dotáhnou do stavu, který umožní uvést výrobek na trh, a stejně se najde někdo, komu se nelíbí, že že harddisk s vyšší kapacitou neni ve všech parametrech lepší než HDD s kolmým zápisem. :-(
SSD taky měly ze začátku spoustu problému, po pár letech vývoje byly problémy odstraněny. Takže bych si tipnul, že do roku 2020 bude doladěný firmware SMR HDD, tak aby nedocházelo k degradaci výkonu, HDD s kolmým zápisem se přestanou vyrábět.
Nelibi, protoze
1) Ty parametre az tak netrapi, ten problem tam je spis ta nekonzistence - disk, ktery nahodne prestane odpovidat na pozadavky OS na minuty, protoze si potrebuje udelat poradek, je nepouzitelnej...
2) HDD uz davno maji vlastni pomerne vykonny pocitac na plosaku, meli svy kejkle udelat tam
3) kompilovat jadro nikdo nebude, myslite si ze nekdo bude pokazde kdyz vyjde update na jadro, znovu kompilovat ? navic patchovat jadro nejakym kodem z githubu, na produkcni masinu ? houby, na todle vam vsichni s...
4) SSD ty problemy vynahrazovali radove jinou rychlosti - tendle disk ma akurat o par 10 procent vyssi kapacitu, kdyby to melo 100T tak at, ale s 10T na to s...
5) do 2020 doufam uz davno bude HAMR a tadle sr**ka se porouci tam kde patri - do propadliste dejin
SMR pri dobrom nastaveni ceny zmysel ma!
dokonca aj agresivnejsie nastavenie (viac prekryvajucich sa stop)...
... ako archivacne medium ;o)
osobne mam TBajty dat, ktore by som kludne mohol hodit aj na nejaku pasku (keby tam nebola tak zufalo nevyhodna cena) - na zive data staci kludne SSD pripadne rychly 1-3TB HDD
Obavam sa, ze HAMR bude este vecsia `sracka`, pretoze prida aj faktor opotrebenia ako je to pri SSD
Ať dělám co dělám, pořád nějak nedokážu přesvědčit sám sebe, že v tom disku hélium vydrží. A to ne 5 let, ale pět týdnů.
Taky jsem s tim mel problem, ale ciste statisticky jsou HE6 nejspolehlivejsi disky na trhu. Takze to asi bude ok.
Čistě prakticky je ta statistika zatím o ničem (vypovídá jenom o tom, že výrobě a testování je věnovaná větší péče). Vypovídací hodnotu bude mít tak za dva roky.
Mozna, ale HE disky se objevili v 2012 nebo 2013, takze ciste statisticky nemuzou existovat statisticke data >3 let doby... takze jestli vydrzi 5 let se jeste jen uvidi :)
To tak pochopitelně je. Ale až budeme za 5 let vědět, jestli ten disk spolehlivý je, tak už bude out-of-sale.
Každý disk je vždy tak trošku skok do tmy. I disky s úplně stejnou technologii a rozdílnou kapacitou mají v dlouhodobých statistikách diametrálně jinou chybovost. A i když koupíte to nejlepší na trhu, můžete narazit na vadnou serii, disky se mohou poškodit při dopravě a chyba se může ukázat až po delší době v provozu, ....
Mate samozrejme pravdu, nicmene predpokladam ze Helium se bude cpat i do pozdejsich generaci, takze procento disku kterym odejde He, by mohla byt zajimava informace. I kdyz buhvi jestli to vubec bude mozne nejak odlisit od ostatnich poruch...
Kdyz se jedna o 10TB dat, jakou alternativu v podobe overenejsi, kvalitnejsi s tym vyssi % moznosti zachovani dat byste odporucil vuci pevnym diskum?
Redundantní pole disků o menší kapacitě. Nic jiného v podstatě neexistuje, pokud se nebavíme o enterprise páskách.
O páskách se nebavme když se bavíme o disku...Alternativu více malých disků beru.
Mě napadá ještě deduplikace. Neříkejte mi že na 10TB disku se nenajdou data která jdou deduplikovat :-)
kdyz ho nacpe filmy, tak nenajdou...
Je tady jedna metoda, která vše splňuje - je dostatečně časově ověřená, téměř absolutně spolehlivá, redundantní, samoopravitelná, s obrovskou hustotou záznamu a nepotřebuje ani elektřinu, přesto vydrží opravdu dlouho. Modří už vědí: DNA.
Přestože je to už dávno vymyšlené, bude ještě nějaký čas trvat, než si koupíme první DNA disky.
Jinak nezbývá než vzít co je. Kupu 4TB Ultrastarů - protože jsou to nejlepší velké disky s nejvyšší spolehlivostí, nacpat je do bedny a k nim fouknout dva Xeony E5, 256GB RAM, OmniOS se ZFS kvůli datové integritě. Do bedny přidat pár kvalitních PCIe NVMe karet na cachování - to zvedne životnost disků. A to celé pověsit na 10/40GbE nebo Infiniband.
Vylepšít se to dá nastavením komprimace v ZFS, případně přidat ramku a pustit on-line ZFS deduplikaci (na 1TB dedup prostoru je potřeba cca 5GB RAM). Šlo by i přidat komprimační/šifrovací/hashovací akcelerátor Intel QuickAssist, jakmile bude do ZFS zaintegrován (což by mělo být brzy) - to umožní použít opravdu silnou komprimaci a odlehčí to procesorům při deduplikaci, protože to bude počítat hashe.
A přidat k tomu páskový changer na LTO-6. 1U na 12 pásek nebo 2U na 24 pásek. Backupovat se musí, i když je pole redundantní.
Pokud je těch dat potřeba uložit více, nezbývá než vyrobit takových beden hodně, propojit je 10/40GbE nebo Infinibandem a pustit nad tím redundantní clusterový filesystém. Třeba LustreFS (teď se to už jmenuje OpenSFS) nebo Ceph.
Nebo počkat na ty DNA disky, jiná dobrá možnost není :-)
Ale zpátky na zem: na 10TB Vám stačí těch 4TB Ultrastárů 8. Protože dávat tyhle obrovité pomalé (relativně, asi 150MB/s) disky do čehokoliv jiného než RAID10 je sebevražda. 2x4x4TB=16TB neformátované kapacity.
Teoreticky by Vám sice stačilo těch disků jenom 6, ale ZFS (obecně žádný moderní COW filesystém) nemá moc rád když se blíží zaplnění. Lepší je nechat ho maximálně do 60-80%. A bez ZFS datové integrity jsou tyhle věci nemožné - ačkoliv ty Ultrastáry mají UBER 1/10^15, není třeba pokoušet štěstí. Větší modely nelze doporučit, jsou nevyzkoušené, příliš drahé a v těch 6TB je hélium, které určitě časem uteče.
Pokud nepotřebujete tak vysoký load, lze místo HGST Ultrastárů použít šmejdy pro NASy, raději lepší - WD RED Pro. Ale musíte počítat s minimálně dvakrát horší spolehlivostí, reálně ještě větší. O řád horší UBER nevadí, protože o to se postará ZFS.
Disky můžete strčit do 1U krabice s osmijádrovým Avotonem a ECC RAM (stačí 16-32GB), AsRock vyrábí takový pěkný servřík a desku s 12x SATA a čtyřmi 1GbE porty. Nebo Supermicro. Pokud tedy snesete občasné vypnutí při výměně disku. Pokud ne, musíte pořídit bednu s hot-swap pozicemi pro 8 kousků, takových je plno jak do racku tak do kanclu.
Nasadit na to můžete třeba FreeNAS, to je funkční a pohodlné. Nebo OmniOS a Napp-it.
A ještě mě napadlo, že bych měl dodat, proč nepoužít 5, 6, 8 TB modely, ale zůstat u 4TB:
1. cenově vycházejí 4TB disky v ohledu na kapacitu lépe, protože nejvyšší kapacity jsou zatím dražší/TB. I kdyby tomu bylo časem naopak, pokud je to možné z prostorových důvodů, je lepší použít menší disky - viz. dále.
2. doba resilveringu pole (zrcadla v ZFS RAID10) se s kapacitou lineárně prodlužuje, tedy čím větší disk, tím delší dobu je při resilveringu pole nechráněno. Což při vyšších kapacitách může vést i k požadavku na trojité zrcadlení. U některých implementací zrcadlení - včetně ZFS - zrcadlení zrychluje čtení, protože se čte ze všech zrcadel paralelně, takže se někdy dělá troj i více násobné zrcadlení i kvůli rychlosti čtení.
3. celkově více disků ve stripu/zrcadle znamená menší zátěž na každý z nich - celkový load se dělí mezi všechny disky. Tím nedojde ani při vyšších požadavcích k překročení doporučené roční zátěže. Takže při vyšším počtu je možné použít horší disky - místo enterprise Ultrastárů třeba WD RED Pro (180TB/rok) nebo WD RED (120TB/rok).
4. výkon téměř lineárně roste s počtem disků ve stripu (do určitého počtu), jak sekvenční rychlost, tak IOPS.
5. do ZFS RAID10 se dají disky za chodu přidávat po dvojicích, přičemž je rozumné používat stejné kapacity, z důvodů vyváženého rozložení loadu; použití menších disků proto poskytuje jemnější granularitu - lze přidávat disky po 4TB, podle toho jak budou přibývat data.
6. u malých instalací (dokud nejde o desítky a stovky disků) není počet disků problém, dokud není disků více než 12-18-24-36-45 protože na tyto počty existují krabice, od 2U do 4U; tyto pomalé disky lze pouštět přes SAS expandér, kdy na každý disk zbude oněch 150-200MB/s pásmo, dnes s použitím SAS3 je omezení poloviční.
7. spotřeba a chlazení nehraje takovou roli - jestli 8 disků včetně potřebného řadiče (třeba nejlevnější 8-port SAS2 HBA) vyžaduje 100W, proti 50W u polovičního počtu 2x větších disků (8TB) to není rozdíl.
8. 4TB disky jsou v provozu už několik let a jsou u nich známy skutečné spolehlivosti a jejich limity, takže lze všechno odhadnout včetně poruchovosti a servisních nákladů - o nových 5,6,8TB modelech se neví skoro nic.
Provozuju několik tisíc parazitních disků ve storage (právě ony 4TB hrají absolutní prim). Nakonec prostě stejně narazíš na problém s místem a s konektivitou. Tj nedivil bych se kdyby si to v DC našlo své kupce i přes zdánlivou nevýhodnost. Protože pokud jich chceš mít 20 no prob, 60 no prob ale třeba 10.000 disků a začneš na cenu koukat jinam (nenašli jsme řešení pod 600kč za pozici aby byla SATA2, hotswap a nebyl to čistý JBOD - tj alespoň expandér). A hlavně je příchod těhle disků dobrý v tom že tlačí zhora efektivitou na doposud opomíjené modely (6tb).
Souhlas. Něco jiného je malá instalace s pár disky, s pár stovkami disků a něco jiného je DC, kde jich budou tisíce a desetitisíce. Každá věc má svůj účel - 10TB SMR disk není pro každého. Je to specializovaná věc na speciální použití. Na něco to bude přímo ideální, jinak by to nevyráběli.
Jen jsem chtěl zdůraznit, že není disk jako disk a že to všechno není tak jednoduché - chce to svoje. Posledních pár let se s NAS, NAS "pro", "near enterprise", enterprise, "cold-storage", "archive" disky roztrhl pytel. Každý výrobce má svoji rodinu produktů a všechny jsou specializované na nějaký účel, každý jinak ošizený a pro jiného zákazníka. Už to není jako třeba před 5-10-ti lety, kdy disk byl prostě disk, byly "normální" disky a enterprise disky. Malé a velké. Všechno je jinak.
A pokud se konkrétní disk použije v oblasti, pro kterou není určen, následuje katastrofa nebo jsou to zbytečně vyhozené peníze, protože by dané zadání zvládlo něco levnějšího. Optimalizaci nákladů a celého systému je nutno věnovat mnohem větší pozornost než dříve. Marketing je jedna věc, skutečnost druhá. Výrobci mlží, prodejci lžou.
Manažer zákazníka tomu nerozumí a často nechápe, proč místo bezva levného NAS disku, na kterém přechovává domácí fotoarchív a filmy, mu nutíme mnohem dražší řešení a pro uložení 10TB si musí koupit drahé disky s kapacitou třeba 32TB (jak píši jako příklad výše) nebo i více, případně ještě nějaká "velmi předražená SSD" pro něj neznámých značek, o kterých v Chipu nepíší. Že by snad disky dělaly datové chyby, to mu zní úplně neuvěřitelně. Často si zvolí levné řešení od jiných dodavatelů a přihrne se až za půl roku, když přijde o data. To je běžný modus operandi, protože osvěta v oblasti ukládání dat je minimální, většina IT profesionálů v tom plave úplně stejně jako diletanti.
A lidi nevědí co chtějí. Jaký bude profil zátěže ? Kolik bude průměrný a špičkový load ? Kolik má být IOPS a rychlost ? Jaké jsou požadavky na dostupnost ? Jak moc jsou data pro ně kritická ? Jak se budou měnit jejich požadavky v čase ? Jaký provozují obnovovací model - kontinuální, roční, tříletý, pětiletý ? Chtějí více optimalizovat pořizovací náklady nebo servisní ? Atd. To všechno úplně mění kritéria řešení.
JBODy jsou drahé, SAS2 je pomalý a SAS3 předražený, ... takže je nutno se osmělit a skočit po 5-6-8 TB discích. Ale některé kompromisy vedou ke katastrofám.
Někdy, když je konvenční řešení moc drahé, je z toho možné vybruslit specializovaným, na míru udělaným řešením. Například zapomenout na redundanci a datovou integritu na úrovni disků a filesystémů a všechno převést na úroveň aplikace, která si tyhle věci bude řešit sama. Nedávno jsme takovou věc páchali - místo různých SAN/NAS bazmeků, ZFS, OpenSFS, Ceph a dalších udělátek se postavilo něco jako Hadoop cluster, velké disky nebyly ani redundantní, ale aplikace si držela - na ZFS onlySSD rychlém poli - transakční systém podle kterého zapisovala všechny "objekty" vícenásobně do toho distribuovaného Hadoop clusteru, sama se starala o datovou integritu na úrovni těch objektů, o jejich komprimaci a deduplikaci, o resilvering dat, archivaci a prostě o všechno. Tím to vyšlo nejlevněji, mohly se použít i ty 6TB (v budoucnu 8TB, možná i ty SMR 10TB) disky, denzita TB/pozice byla nejvyšší a cena minimální, přitom spolehlivostní parametry byly na dostatečné výši.
ano proto místo raidu (na tom cloud backup systému) nejede žádnej raid a data se kopírují fyzicky - přidává to další vrstvu loss-less, kdy můžeme rozkopírováváním sledovat i (je tam atribut kontext tj jedna záloha v čase má furt stejnej kontext název domény, název workstation) to aby fyzicky a geolokačně jeden záloha (tj její pondělní, uterní) snímek nebyl na jakkoliv závislém storage (lokalitou i fyzickým umístěním) a pak pravděpodobnost že nedokážeme dodat třeba i jen 48 hodin stará data leze někam k 12 devítkám. A tam nám žádné raidy ani vyšší logika nevadí. Mj SAS2 pro naše účely archivace (předpokládám že vzhledem k rychlosti i ten 10TB bude archivační) v nějakém řešení pod 60 disků/4U vyhovuje. Pořád máš totiž limit v racku na nějakých 10gbit, a proto je to třeba dělat parazitně tj rack rozdělit na produkční a archivní část a každou krmit jnou sítí. Kdyby tam bylo osazených těch 10TB tj 8x60x10 disků 4,8pb tak to jen nakopírovat desetigigem potrvá déle než měsíc. což u záloh které mají obvyhle umrtnost někdy po 14ti dnech je fakt problém.
Moc pěkný archivační systém !
Problém rychlosti na pomalých discích naši kluci vyřešili tím, že si vypůjčili pár fíglů z peer-to-peer úložných/sdílecích sítí (Bittorent, Napster, ...). Požadovaný objekt je rozsekán na kousky a ty se tahají paralelně, z uzlů clusteru které mají zrovna čas, volné IOPSy a volnou konektivitu, ze všech dostupných kopií objektu. Zatížení clusteru a linek mezi uzly se sleduje, plánuje (kvůli archivacím), vyhodnocuje - není to tak složité, jak to možná zní. A funguje to nejen rychle, ale je to i "bombenfestung". A také blbuvzdorné, uzly se vzájemně najdou a ohlásí do centrály, i pokud někdo udělá chybu v administraci a třeba změní IP adresy. Také označení a identifikace disků je unikátní, takže nevadí když servisáci disky vytahají z hot-swapů a vrátí je tam úplně jinak. Umožňuje to velkou granularitu v dostupnosti a rychlosti uložení - objekty mohou být uloženy třeba všude nebo také jen ve dvou kopiích. Prioritně na pomalých uzlech, rychlých uzlech, atd. Detaily rozhodují.
Rychlosti disků/rychlosti sběrnic/rychlosti sítí - kontra - disková kapacita, archivační kapacita. To je dnešní hlavní problém, kromě UBER a spolehlivosti. V malých i velkých nasazeních. Než se skopne 1:1 4TB disk, trvá to v optimálním případě 8-16h, podle toho jak je to dobrý/mizerný disk.
A je docela otrava s 10GbE - je to pomalé, přesně jak píšete. Mnohem lepší a ne o moc dražší řešení pro serverovnu je Infiniband, dnes nejčastěji QDR. Mimo absolutně nejnižších latencí má výhodu RDMA protokolů, heterogenní implementaci (která funguje napříč operačními systémy i napříč dodavateli IB bazmeků - což se o 10GbE nedá říci), skládání více spojů kvůli redundanci násobí rychlost (i pro jednotlivé přenosy, ne jako u Ethernetu). Takže každý rack má na sobě redundantně dva top-of-rack IB switche a jede to 80Gbit (2x 40Gb IB QDR). Fat tree. Absolutně konvergovaná síť, jde přes to pouštět všechno. 80Gbit je pro každý rack lepší než 2x10Gb. IB je - mimo těch dalších výhod - 4x rychlejší než 10GbE a přitom není 4x dražší.
Přichází doba cloudových úložných systémů - ve stylu jak píšeme oba - které nebudou trpět nedostatky RAIDů, ZFS, ext4, NTFS, ... Budou mít svoje vlastní nedostatky :-)
Nový software, nové chyby.
"zápis probíhá dokonce rychlostí pouze 68 MB/s. Je tedy nasnadě, že zde došlo i k poklesu rychlosti rotace, aby se vůbec dařilo spolehlivě vystavovat hlavičky nad stopy a trefovat sektory."
Zrejme nepochopeni jak funguje SMR. Vzhledem k tomu, ze nekolik stop se mezi sebou prekryva z duvodu, ze sirka stopy je mensi nez fyzicka sirka hlavy, tak pri zapisu je nutne prepsat spolecne s konkretni stopou i prilehle stopy ve skupine. A predpokladam, ze presne tohle resi upraveny ovladac, shlukuje zapisy do skupin prekryvajicich se stop, tak aby nedochazelo opakovane k jejich prepisum.
Pučte mi někdo na rozumnou dobu pár takových disků a já vám je otestuju, klidně na Linuxu i Windowsech, nebo kombinaci obojího. Než si sám vyzkouším, jak se to chová, budu tak maximálně slintat, protože ta kapacita se mi prostě líbí. Chtěl jsem si koupit šindelové 8TB Seagaty, protože měly cenu za terabajt pod jedním tisícem korun, ale nedošlo na to (nedostatek financ).
Jen aby se časem z těch šindelových SMR disků nevyklubalo ono vypečené write-only médium.
Jestli chcete, mohu vám takový bazmek dát - mám jedno SSD, které se tak chová. Zapíšete cokoliv, ale čtete jen samá FFFFFFFF (nebo nuly, to už si nepamatuji). Ale zase to má tu výhodu, že kapacita je opravdu nekonečná.
Doufejme, že než dojde na lámání chleba, objeví se HAMR záznam nebo memristory. Nebo něco jiného.
Takový disk je ideální jako /dev/null :-D
Jj. A pokud fakt vrací nuly (to už nepamatuji, musel bych to vyhrabat), tak nahradí i /dev/zero. Multifunkční bazmek !
Příští rok to začne za těžký prachy prodávat Apple pod názvem iZero.
To bude trhák: iZero, nekonečná kapacita. Ideální na archivaci zbytečných dat, i přísně tajných. Vrací vždy nulu ! Neprolomitelné šifrování. Zaručeně write-only.
S tím reálným testováním je to recht. Když u se tu rozebírají velké kapacity a způsoby co místo téhle 10TB novinky, tak na webu a nejen českém je spousta planých diskuzí na téma defragmentovat či nikoli točivé RAID pole. Tak s jednou otestovanou informací do mlýna. 20TB RAID6 pole s 20TB logickým svazkem na NTFS ROZHODNĚ pravidelně defragmentovat. Jinak při 70% fragmentaci pokus o vysypání koše s pár desítkami GB znamená totální zamrznutí IO operací u disku na mnoho minut, shození probíhajících přenosů LAN. Prakticky paralyzovaný OS. Pozn. pro diskutéry: samozřejmě, že data jsou fyzicky defragmentovaná a rozhozená po poli podle velikosti STRIPE. Problém, je ve filesystému a jeho defragmentaci. Což je jiná vrstva. Závěr: Ono s tím softem pro 1OTB HGST to asi bude podobně. Tipuji, že půjde o nějakou optimalizaci snižující defragmentaci disku. Když se od softu firmware dozví jak velký soubor vlastně po sběrnici poputuje a má tak šanci to zapsat v souvislých blocích a kromě fyzických problému při seekování se také vyhnout gigantické tabulce. Plus možná to co píše výše uživatel Stealth..
Velká data mají svá úskalí.
Mimo prakticky neřešitelného problému s defragmentací (viz. níže) je zde problém průběžných oprav. Při UBER chybách velkých disků, kdy je kapacita již v řádu UBER, se musí u všech implementací - včetně ZFS - provádět scrubbing (drbání) průběžně, stejně jako se to dělá u ECC pamětí. Aby počet chyb nepřerostl možnosti zabezpečení (opravného polynomu). To u velkých polí zabírá část výkonu, tím více, čím s horšími disky se pracuje (tím myslím UBER 1/10^14). Jakmile se to neprovádí, dojde ke katastrofě. Hlavně všechny klasické RAID6 v tomhle mají problém - z podstaty neřešitelný (protože při poruše disku degradují na RAID5, kdy se už UBER chyby nedají opravit). RAID5 je z tohoto důvodu mrtvý koncept úplně.
Problém fragmentace je hlavně u moderních COW filesystémů. Jako je třeba ZFS. Každý zapisovatelný snapshot (klon) znamená fragmentaci. Každý "light provisioning" soubor znamená fragmentaci. Vlastně každá změna souboru znamená fragmentaci. Fragmentační katastrofou je on-line deduplikace, už z principu. Je to neřešitelné - požadavky jdou ostře proti sobě, je to buď anebo. Můžete mít jedno (COW zápis, writable snapshoty - klony, light provisioning soubory, deduplikaci) nebo druhé (defragmentovaný filesystém). Ne oboje najednou.
Jediné skutečné řešení problémů s fragmentací - protože jsou z podstaty neřešitelné - je to neřešit, ale nasadit všude SSD - těm to nevadí.
Po několika letech - i dříve, když se těch vyspělých možností, tj. writable snapshoty - klony, ... nadužívá - fragmentace vzroste natolik, že výkon jde rapidně dolů. Také to velmi namáhá HDD, neustálé "škubání hlavičkami" v celém rozsahu mnoho disků nevydrží, jen ty nejlepší enterprise kusy - třeba ty 15k modely malých kapacit. Proto se moderní věci jako on-line deduplikace moc v praxi nepoužívají, leda ve speciálních případech (třeba prostor pro mailové servery firem bývá vhodný objekt pro deduplikaci - mnohamegabajtové přílohy mailů krouží firmou ve stovkách kopii) a téměř výhradně na SSD discích, kde to nevadí. U velkých HDD je výhodnější použít pouze on-line komprimaci a na deduplikaci zapomenout - navíc deduplikace vyžaduje velkou RAM (u ZFS na každý 1TB deduplikovaného disku asi 5GB RAM na hashe).
ZFS, například, dosud žádnou skutečnou defragmentační utilitu ani politiku nemá. Řeší se to intenzivně, časem snad něco vypadne z komunity kolem BTR (Block Pointer Rewrite). Work-around je v tom, když po pár letech fragmentace naroste (cca nad 70%), pole vysypat na backup (obvykle na páskovou knihovnu), znovu inicializovat a napustit. To ovšem nějakou dobu trvá, třeba také pár týdnů, u mamutích instalací v datacentrech. Ale s tím se počítá už při návrhu - velké instalace mají redundanci na mnoha úrovních, nad samotnými filesystémy (ZFS) se používají clusterové aplikace (OpenSFS, Ceph, ...).
Fragmentovaný filesystém - i ve stavu, kdy všechno běží super - je nebezpečný také v té věci totálního mazání, přesně jak píše VCR33 výše.
Například: když budete někde ve velké instalaci sedět u ZFS jako správce, nikdy nedělejte příkaz "zfs destroy ...", pokud nevíte docela přesně okolnosti. Může to totiž spustit řetězovou reakci mazání odkazů přes všechny udělané klony a změny souborů až k prvopočátku vesmíru (k bodu zrodu ZFS instalace) - takže se z toho vyklube třeba 500 milionů IO operací, když instalace pár let běží. A to si pak počkáte - výkon pole jde dolů na desítky minut až dní (když je všechno špatně a lidi jsou idioti, což často jsou). Mnoho datacenter takhle padlo přímo na hubu. A stává se to nejen u ZFS, ale u všech moderních filesystémů včetně NTFS, VMFS5, clusterů, ...
Všechno má zkrátka svoje pro a proti.
"Tipuji, že půjde o nějakou optimalizaci snižující defragmentaci disku"
Vedle, a pritom se staci podivat na tu github stranku (link na konci clanku)... V readme je jasne napsano co to dela, a defragmentace se nekona. Je to obycejna user-space kniznice pro lowlevel ovladani disku. Tj misto zapisovani po sektorech muzete zapisovat / cist cele zony. Tot vsjo...
Účelem té knihovny je ale právě to, aby nedocházelo k fragmentaci a propadům ve výkonu, jako se to děje u 8TB SMR Seagate.
Děkuji, správně měla věta znít: "Tipuji, že půjde o nějakou optimalizaci snižující fragmentaci disku" :-)
Slava, konecne se SSD kvalitou a vydrzi vyrovnali HDD ... bohuzel, nedoslo k tomu zlepsovanim SSD, ale zhorsovanim HDD. Pass. Zustanu u mensich disku.
SSD už překonaly HDD ve spolehlivosti, tedy alespoň ty od těch lepších výrobců, HDD mívají poruchovost 1-5%, SSD Intel 0.5%. Co se výdrže týká, tak SSD sou na tom řádově lépe než HDD, moje Intel SSD 320 300GB má předpokládanou životnost >100let.
Přesně tak.
Téměř každé lepší SSD má MTBF 2 miliony hodin. To je při 24/7 provozu AFR 0.44%. Tedy každý rok z 227 disků chcípne jeden.
Z HDD to umí jen nejdražší enterprise 10k a 15k modely, třeba ty Seagate Savvio. Nebo HGST 15k. Z velkých >TB disků tohle umí jen HGST Ultrastary - a je to pravda ověřená praxí, ne jen reklamní žvást.
U všech ostatních značek, Seagate NAS xxx, WD RED (Pro) udávané hodnoty MTBF jsou mnohem nižší - 1 200
000 hodin, ale to jsou hodnoty z říše snů. Skutečnost je rapidně horší. AFR je 4-8% docela běžně.
Další věc je, že u HDD je MTBF funkcí zátěže a změn teplot, chvění. Poruchovost roste s růstem zátěže minimálně lineárně, někdy až exponenciálně. Pokud dáte HDD pořádný kouř, do roka jich je polovina po smrti, pokud se nebavíme o těch nejdražších.
Výrobci tohoto faktu využívají k tomu, že udané MTBF hodnoty jsou vázány k blíže nespecifikovanému loadu, logicky co nejmenšímu (někteří poctivější připojí hvězdičku a vysvětlivku, obvykle poněkud enigmatickou, takže se z toho nedá nic odvodit - je to spíš alibi proti případným soudním žalobám a reklamacím).
To u SSD neplatí - tedy pokud nejde o zápisy. Jediným nebezpečím pro SSD je špatné chlazení.
A výdrž HDD vyšších kapacit je úplně směšná. WD RED může nakroutit ročně - čtení a zápis dohromady - jen 120TB. WD RED Pro 180TB. WD RE4 (eufemisticky označovaný za "enterprise") má roční loud 550TB. Seagate je na tom naprosto stejně, až na to, že raději tyhle hodnoty ani nepublikuje.
MTBF a hodnoty výdrže ("doporučený" roční load) se u levnějších, desktopových, notebookových HDD pro jistotu ani nezveřejňují, aby se kupující nevyděsili.
Proto je docela směšné, jak se diskutuje o výdrži SSD se zmenšováním litografie - 15 nm má mít jen 1000 přepisů buňky ? To je fakt katastrofa ! WD RED má ročně jen 30 přístupů (120/4 pro 4TB disk), zápis i čtení dohromady, na každý bajt, průměrně. To ovšem nikoho neděsí.
SSD také nemají problémy s fragmentací. To je čím dál důležitější vlastnost, s příchodem nových COW filesystémů, s používáním klonů, deduplikací, light provisioningem.
A to jsem se ještě nezmínil o chybách. UBER. Každé lepší SSD má alespoň 1/10^15, enterprise modely 1/10^16 - to nemá vůbec žádný HDD.
Běžné velké disky mají UBER 1/10^14 (nebo také mnohem horší, pokud je trochu "nabouraný" nebo se čínskému dítěti ve fabrice "nepovede"). To je hodnota, která bez zaručení datové integrity nějakou softwarovou nadstavbou činí tyto disky v zásadě nepoužitelnými.
Problém také je v tom, že tato hodnota u HDD závisí na dalších parametrech, hlavně teplotě a chvění. Což se SSD netýká.
Zkrátka SSD je mnohem a mnohem spolehlivější a lepší technologie na uložení dat, než všechny HDD.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.