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.
Dobré harakiri. Takový disk když umře tak z něj data nedostane ani bůh. Zlaté SSD - z toho je sice také v případě poruchy nikdo nejspíš nedostane, ale aspoň je rychlé a netrpí tak brutálním propadem výkonu. Nadvláda SSD se nezadržitelně blíží. SSD je již jen 10x dražší při stejné kapacitě. Pokud se něco honem rychle nestane a klasické disky nebudou najednou s kapacitami +- 25TB tak je SSD do dvou let dožene s poměrem Kč/GB
Jen pro zajíavost. Za 15 let jsem nashromáždil asi 500GB dat. (a to bych klidně větší půlku jistě mohl bez ztráty smazat) To znamená že takový disk by mi stačil na 240 let.
Stane se - SSD narazí na fyzikální limity. Navíc SSD má jednu trošku nepříjemnou vlastnost - když se vypne a po nějaké delší době se zapne, tak tam ty data taky nemusí být (a čím novější výrobní technologie, tím kratší dobu drží)
Tím nechci zatracovat SSD - jako systémový a pracovní disk je naprosto super a v této oblasti už mechanické disky celkem jistě vytlačuje, ale jako "datový sklad" to není ta úplně nejvhodnější technologie.
Trochu bych brzdil. Všechny SSD s 10kč/GB jsou na 14nm. Kam myslíš, že se podaří jít, než se narazí na limit? 5nm a bude konec. A mimochodem, 5nm, to se bavíme o roku 2022-2025.
Navíc je zcela očividné, že cena neklesá lineárně s hustotou tisku do křemíku. Čím menší rozteč, tím menší výtěžnost a tím menší úspora.
Na 1kč za GB jako ui HDD se dostaneme nejdříve za 7 let a to ještě u jiné technologie nežli NAND buňky.
Mensi nanometry ale preci nejsou vubec treba. Staci tam tech cipu nacpat proste vic. A ze by se jich tam veslo. A je vcelku jedno jestli 2d a nebo 3d. Je to jen o cene. Staci 10x zlevnit vyrobu.
Jo to je takový detail, jen 10x zlevníme výrobu. Ani nevíš, jak taková cenotvorba u IO funguje, ale řešení už máš. Te´d jen aby ti pitomí inženýři koukali to tvé řešení uvést do praxe :-D
A nebo udělat masivní lobbing a protlačit dotace na SSD přes EU :-)
PS - proti EU nic nemám, jen domácí politici většiny členů dost se.ou na to, aby dohlíželi na byrokratický aparát, protože se pak mají doma na co vymlouvat a sbírat politické body.
Zato ty jseš nepochybně expert na výrobu SSD. Výroba SSD se bude zlevňovat a kapacity narůstat protože po nich bude stále větší poptávka s rostoucími kapacitami. Nikdo soudný si nebude dávat do počítače nějaký točivý disk protože má větší kapacitu a spolehlivost ze stejného důvodu jako si dnes skoro nikdo nedá do počítače páskovou jednotku. Klasické HD tu budou ještě dlouho to je jisté, ale jejich použití už nebude ve stolních počítačích a domácích backupech. A jelikož se prodává stále více SSD tak se do jejich vývoje stále více investuje narozdíl od klasických disků. Já osobně si myslím že konečná klasických 3,5 HD je někde okolo 500TB a dosáhne se jí asi za 20 let. V té době bude mít každý ale v telefonu 10TB SSD a ve stolním počítači 250TB SSD v cenách podobných jako jsou dnes za běžné kapacity. Nikde také není psáno že SSD bude stále nějaká hloupá FLASHka která má své fyzikální omezení. Klasické HD také nesedí na zadku s MFM zápisem jako před 30ti lety a u SSD to bude stejné. SSD je prostě technologie která má budoucnost a jednou klasické HD překročí cenou, kapacitou i trvanlivostí. Já si myslím že zhruba za 2 roky se +- prolnou ceny 1TB disků SSD s cenou 1TB HD. A to už je sakra dostačující kapacita pro běžného uživatele.
SSD neni technologie. Technologie je NAND Flash a ta budoucnost nema. Pokud se objevi nejaka jina technika a bude se ji taky rikat SSD, tak to bude jenom marketingovy nazev a nebude to mit s faktem, ze v NAND flash ta budoucnost proste neni, nic spolecneho.
NAND flash je vhodna na system, ale ne na data. Maximalne jako cache neboli s tim, ze ty data mate jeste nekde jinde, bud na cloudu nebo doma na NAS. A jak v cloudu, tak v domacim NAS, budou jeste leta HDD, akorat je mozne, ze uz za 2 roky budou bezne sindelove.
Nova technologie se do dvou let muze objevit, ale ne rozsirit, natoz dostat na cenu 1TB shodnou s HDD. NAND flash se mozna na podobnou cenu pro 1TB dostanou, ale pouze za cenu jeste vyraznejsiho snizeni spolehlivosti.
Zato ty jseš nepochybně expert na výrobu SSD. Výroba SSD se bude zlevňovat a kapacity narůstat protože po nich bude stále větší poptávka s rostoucími kapacitami. Nikdo soudný si nebude dávat do počítače nějaký točivý disk protože má větší kapacitu a spolehlivost ze stejného důvodu jako si dnes skoro nikdo nedá do počítače páskovou jednotku. Klasické HD tu budou ještě dlouho to je jisté, ale jejich použití už nebude ve stolních počítačích a domácích backupech. A jelikož se prodává stále více SSD tak se do jejich vývoje stále více investuje narozdíl od klasických disků. Já osobně si myslím že konečná klasických 3,5 HD je někde okolo 500TB a dosáhne se jí asi za 20 let. V té době bude mít každý ale v telefonu 10TB SSD a ve stolním počítači 250TB SSD v cenách podobných jako jsou dnes za běžné kapacity. Nikde také není psáno že SSD bude stále nějaká hloupá FLASHka která má své fyzikální omezení. Klasické HD také nesedí na zadku s MFM zápisem jako před 30ti lety a u SSD to bude stejné. SSD je prostě technologie která má budoucnost a jednou klasické HD překročí cenou, kapacitou i trvanlivostí. Já si myslím že zhruba za 2 roky se +- prolnou ceny 1TB disků SSD s cenou 1TB HD. A to už je sakra dostačující kapacita pro běžného uživatele.
Velmi, velmi se mýlíte, budiž k vašim datům osud milostiv. SSD, jakkoliv je to skvělá věc pro systém a rychlé přístupy, je poněkud cenově nevýhodný pro dlouhodobé skladování dat a zcela nevhodné pro zálohování (kde se stále zapisuje a víceméně nečte). Pro archivaci by to použil jen tajný agent, který potřebuje aby se data po určitém čase po odpojení samovolně skartovala.
Pochopitelně kdo cvakne fotku, hned ji nacpe na fejsbůk a zapomene, tomu to může být jedno, ale kdo něco vytváří, ten bude HDD potřebovat dokud nebude něco spolehlivějšího.
A to budou za par let prave ssdcka :-)
pomer cena / kapacita neni jedinou veci v rozhodovani kam se trh pohne. Pevne disky byly vzdy kompromisem mezi rychlosti a kapacitou. Nicmene se priznam ze se sam rozhoduji ze bych svoje pristi uloziste udelal jinak. Ted drzim disky v raidu a priste si dokazi predstavit jeden velky disk zalohovany 1x tydne paskou. Ikdyz pasky jsou porad jeste drahe (hlavne ty zaznamove stroje). Nicmene pokud budou disky takhle mizerne, tak se na raid muzu v budoucnu vykaslat a mozna zkoncim u 2 stejne velkych disku s tim ze jeden pojede a druhy se bude zapojovat jen jako cold storage zaloha.
Pasku jsem pouzival na zalohovani asi pred dvaceti lety a je to neskutecne nepohodlna zalezitost. Zalohovat s tim ze se nebude nejspis nikdy cist (jen v pripade havarie) jeste dobry ale jinak ne. Ono kdo natacel treba video jeste na kazety si dokaze predstavit co to muze byt za chutovku hledat jednu konkretni pasku natocenou pred dvema lety. Ono na zaznamova media se plne vztahuji kvantovr zakony (snad jeste vic nez na cokoliv jineho) a takova kvantova fluktuace dokaze pekne pozlobit kdyz date pasku na svoje misto do regalu a najdete ji ( v lepsim pripade) za pul roku nekde uplne jinde protoze zrovna nekomu prekazela.
Kuprikladu a jsem nashromazdil 200GB dat za necelych 14dni.. Uz to tak je, ze kazdy mame trochu jine potreby.
To bylo uvedeno jen pro zajímavost :-)
porno se nepočítá :)
Prečítané celé...vďaka!
Zatiaľ zostanem pri 4-5 TB diskoch, tieto SMR nemusia byť zlé na to, čo majú priamo v popise - archiváciu. Dokážem si predstaviť mať NAS s 2-4 4TB diskami a z nich robiť zálohu na tento archive.
Tak by som to asi aj robil, nie z NAS ale z PC v domácnosti archiváciu na sieťový disk. Odosiela sa väčšinou len jeden veľký súbor občas delený na časti, ale opätovne sa k nim pristupuje až keď je problém. Takto mám niekoľko 2TB externých diskov. Len raz zapísané dáta, ktoré zostávajú v PC a ako poistka aj na externých diskoch, z ktorých ich už viac nečítam, nemažem. Zaplním a dám nový.
Pokiaľ SMR nebude časom strácať dáta, prečo nie?
Kiež už by tu boli 300GB-1TB BR disky ohlásené v 2014.
Navrhuji místo hard-disku udělit přímo Wiftovi zlaté ocenění serveru DIIT za zásluhy a skvělou informativní (a investigativní) recenzi nově přicházející technologie. Je to radost číst.
Kdo je pro, dejte plus...
Místo toho raději sdílejte, abych si mohl koupit druhý a udělal článek o tom, jak makaj v tom zmiňovaným RAIDu ;).
Najprv som chcel napisat ze pole (aj mirror) zomrie na nepouzitelnost do par tyzdnov, ale bude to asi uz pri prvom zaseku pri vacsom zapise. Vyleti prvy disk na timeoute a druhy pojde hned za nim. (Ak nie, nasledny resilvering moze trvat radovo mesiace.)
K nahodnemu zapisu, kt. je robeny najprv sekvencne:
1330 IOPS po dobu 135 sekund to mame cca 179500 nahodnych zapisov (po 64 kiB = 65536 B). NAJPESIMISTICKEJSI SCENAR je: 179500 zapisov do 128 MiB SMR zon, co je cca 179500 x 128 x 1048576 = 24,1 TB na upratovanie !!! A to iba kvoli necelym 12 GB. Toto upratovanie pri priemernej rychlsoti cca 140 MB/s (od cca 200 MB/s na okraji po 90 MB/s pri strede platne) trva cca 172000 sekund = cca 48 hod, takze 14-19 hod je o hodne lepsie. Kratsi cas mohol byt sposobeny tym, ze niektore nahodne zapisy boli urcene pre tu istu SMR zonu?
Dalej sa naskyta zamyslet sa nad odporucanim vyrobcu zapis 180 TB/rocne. A ake % z toho ma byt nahodny a ake % sekvencny zapis. Cim nahodnejsi, tym horsie. Ked 12 GB cisto nahodneho zapisu vygeneruje max. 24,1 TB (v tomto pripade zrejme realne "iba" cca 8 TB) dat na upratovanie, kolko dat na upratovanie vygeneruje zapis 180 TB dat s istym % nahodneho a istym % sekvencneho zapisu? Cisto nahodnym zapisom tam 180 TB NIE JE MOZNE zapisat, pretoze 12 GB nahodneho zapisu vygeneruje upratovanie takmer na cely den a rok ma iba 365 dni, takze cisto nahodnym pristupom mi to v ramci realne plynuceho casu (potrebneho na upratovanie) vychadza asi tak na 6 TB cisto nahodnych dat rocne.Viac sa pri realne plynucom case cisto nahodne zapisat neda, upratovanie po cisto nahodnom zapise by rocne zabralo presun cca 4 PB (petabajtov). Takze z tych 180 TB rocne moze byt cisto nahodnych max. 6 TB :)))))))
6/180 = 3,3%. T.j. ak tento disk budete pouzivat na nahodne zapisy vs. sekvencie zapisy na viac ako 3,3% pre nahodne zapisy, ste v prdeli. A to permanentne. Absolutnu nevhodnost na nahodne zapisy by bolo treba napisat aj na disky velmi velkymi pismenami ...
Nakoniec si uvedomme, ake je vlastne TEORETICKY dlhobodo spriemernené IOPS tohoto examplara hardveru, ktory je absolutne nevhodny na nahodne zapisy. Odpoved je 1, slovom JEDNA IOPS !!! To je totiz rychlost, ked sa pri spriemernenej kontinualke 140 MB/s stihne pri upratovani prepisat 128 MiB SMR zona. Realny test potom ukazal, ze to je 3x viac, t.j. asi 3 IOPS !!!!!
Inak: 179500 nahodnych zapisov (1330 IOPS po dobu 135 sek) a upratovanie trvalo 14-19 hod, zoberiem 16 hod. To mame 179500/ (16*3600) = cca 3 ...
ESTE RAZ: dlhobodo spriemernené IOPS tohoto examplara hardveru je 3 IOPS !!!!!!!!!!!
Takze SSD radovo 10k az 100k IOPS, HDD radovo 100 IOPS a tento kus SMR HDD defacto 3 IOPS.
Disk je Archiving, takze by ho MALI kupovat ludia, co chapu funkcionalitu a urcenie tohto disku...
to hej, ale ja len pocitam a hladam ekvivalenty istych pojmov
Mam tento disk od januara - a kupoval som ho napriek mnozstvu negativnych recenzii (WIFTova je asi prva kvazi-pozitivna resp. nie je z kategorie "WFT?") Nato, naco je primarne urceny, je v pohode, 12GB buffer je dostatocny pre obcasne 20-50-100GB zalohy fotiek alebo denne presuvanie z SSD buffera.
Mozno mali popracovat na fw a pri spusteni upratovania na pozadi viac "pritiahnut" datovy tok, potom to neunosne pulzuje a je sanca ze aj niekedy vytimeoutuje. Pri "obcasnom" archivovani je to jedno, ale pri inicialnom naplneni disku to bola tragedia, vyriesil som to salamunsky/empiricky - miesto pulzovania rychlosti (MB/s) 120-30-0-120-30-0-120-30-0-... dlhodoby priemer ~20MB/s som nastavil pri kopirovani limit 50MB/s a slo to skoro kontinualne, v priemere teda asi 2.5x rychlejsie a hlavne clovek nemal zly pocit z "activity time 100% write speed 0" co u beznych (SDD) diskov znamena blizku smrt resp. "dalsi chod odchod".
Ako uz bolo spomenute, aj kvazi-sekvencne zapisy nie su unosne premapovatelne, a kedy vydali Host-aware verziu (pripadne prepinatelny hybrid Drive-managed+Host-aware) tak predpokladam ze driver by riesil presne tieto pripady "prechlastania".
Asi teda jedine coho sa clovek moze bat, je ta dlhodoba neoverenost SMR technologie, ale to je nieco podobne ako rakovinotvornost mobilov alebo mikrovlniek, simulaciami tam nejaka korelacia asi bude, ale realitu ukaze az dostatocne dlhy cas.
3 IOPS je pouze nejhorší možný výkon při absolutně nevhodném způsobu použití, při správném způsobu použití bude výkon zhruba stejný jako u neSMR HDD.
SSD jsou na tom podobně, výkon >10k IOPS z nich dostanete pouze po krátkou dobu, u horších SSD může za pár minut klesnout až někam k nule - http://images.anandtech.com/doci/9756/bx200_480_pc1.png
Asi si nepochopil co znamena IOPS. Aj v tom tvojom obrazku je marketingovych 50k-70k IOPS najlepsi scenar, nie najhorsi, kedze IOPS je v zasade 10k, sem tam v okoli 25k.
Podobne pri tomto SMR HDD je z dlhodobeho hladiska (tak ako som tu hodnotu myslel) 3 IOPS NAJLEPSI MOZNY pripad pri nahodnom pristupe (NIE NAJHORSI) - pretoze napr. 100 sekundove kopirovanie 15 GB MKVcka (kontinualkou 150 MB/s) vlastne znaci potrebu 0,01 IOPS (stotina IOPS). Napr. kopirovanie 5 MB suborov rychlsotou 150 MB/s znaci potrebu 30 IOPS.
Re: „1330 IOPS po dobu 135 sekund to mame cca 179500 nahodnych zapisov (po 64 kiB = 65536 B). NAJPESIMISTICKEJSI SCENAR je: 179500 zapisov do 128 MiB SMR zon, co je cca 179500 x 128 x 1048576 = 24,1 TB na upratovanie !!! A to iba kvoli necelym 12 GB. Toto upratovanie pri priemernej rychlsoti cca 140 MB/s (od cca 200 MB/s na okraji po 90 MB/s pri strede platne) trva cca 172000 sekund = cca 48 hod, takze 14-19 hod je o hodne lepsie. Kratsi cas mohol byt sposobeny tym, ze niektore nahodne zapisy boli urcene pre tu istu SMR zonu?“
Spíš bych tipoval na ty 256MiB zóny. A pokud těch zápisů bylo skutečně ~180000, tak je to v průměru 6 zápisů na zónu, kterých je 29808.
Ať tak, či onak - nemůžeš zahájit úklid 24 TB dat, když má disk jen 8 TB :).Takže to znamená prostě 8 TB přečíst a zase 8 TB zapsat, což v článku odpovídá HD Tach RW testu a ten se dělal o něco víc než 24 hodin (ono to ve skutečnosti znamená 8TB + na přeskáčku 12 GB načíst a 8 TB zapsat, plus to zdržují přesuny hlaviček).
No pokial by boli tie SMR zony 128 MiB, tak by ich bolo 2x viac (59616) a kazda by bola prepisana iba 3x, nie 6x. Ak by kazda bola prepisana 3x, potom by sa muselo upratovat 24 TB, nie 8 TB, to je uplne pochopitelne a jasne. To ze disk ma kapacitu iba 8 TB je uplne irelevantne, kvoli upratovacej rezii SMR zon si to moze prehadzovat aj 50x a teda teoreticka potreba upratovat hoci aj 400 TB nie je nemozna, pretoze to proste bude prepisovat mnoho-krat. To sa ale ocivine nedeje, upratovanie obnasalo zrejme iba 8 TB (kapacitu disku) a kazda SMR zona bola zapisana/upratana iba raz napriek tomu, ze na nu smerovali 3 nahodne zapisy v pripade velkosti 128 MiB, alebo dokonca 6 nahodnych zapisov v pripade velkosti 256 MiB SMR zony.
Disk zrejme zobral vsetky nahodne zapisy z 12 GB PMR (nonSMR) cache, ktore vsetky smeruju do jednej konkretnej SMR zony (ci uz takychto nahodnych zapisov bolo 3 alebo 6) a na jeden jediny raz ich zapisal do prislusnej SMR zony.
Mam je doma dva, v RAID1 (resp. WSS s ReFS a zapnutou kontrolou checksumu).
Pod windows se to chova vicemene stejne jako jeden disk, vsechny veci z recenze funguji presne stejne i pri dvou discich v mirroru (akorat thrashing cache prichazi o chvilku driv nez pri jedinem disku - predpokladam ze se vzdy nahodne zaplni jeden drive nez druhy).
Puvodne jsem ale chtel na tom serveru mit linux a BTRFS. Tento napad jsem byl nucen opustit. Jakmile se zaplnila cache, nasledoval kernel panic. Syslog sel na ten archivni disk, takze nevim co presne se s dlouhymi timeouty nedokaze smirit... Nainstalovat W2012R2 bylo jednodussi, nez to resit :-).
Mám doma ST6000VX0011-1T317Z, ak sa nemýlim tiež s prekladanými stopami. Mám na tom BTRFS a istú dobu som tam bežal aj systém (bol to jediný disk na počítači). Nepamätám si jediný „kernel panic“. Ale bežím tam staršie jadro 3.18.31-gentoo, kvôli DVB-T kartám. Primárne je to počítač na mythtv a prehrávanie nahrávok, či filmov.
Ďalej sa používa na prezeranie internetu, skype a zálohovanie. Aktualizácie baličkov (teda kompilovanie) som robil zväčša v RAM-ke.
Problémy začali, keď sa deti chceli na ňom hrať minecraft, tým pádom začal asi zapisovať veľa malých vecí a po určitom čase (tak 5 až 20 minút) to začalo sekať. Samozrejme počas toho často dačo nahrával a firefox, tiež pracuje aj keď nikto zrovna na neho nepozerá.
Tak som tam nahodil staršie SSD 120GB, ktoré som mal. Prehodil tam systém a niektoré dáta a všetko chodí ako má.
K tomu BTRFS mam taku teoriu. V linuxe je pre SATA zariadenia standardne nastaveny timeout tusim 30s, vo windows je to pokial viem o dost viac. Cize je dost mozne, ze jakmile si zaplnil cache tak tie operacie trvali dlhsie ako 30s a vyhodili oba disky z pola. (co znamena kernel panic ak si na tom mal aj root)
Overit si to vies cez:
cat /sys/class/scsi_generic/*/device/timeout
Tiez to vies nastavit, tak ze tam cez echo posles nieco ako 180 sekund, alebo viac. Ten default je celkom rozumny pre standardne SATA disky, ale pri SMR to zrejme bude treba trosku upravit.
To len tak naokraj ak by si chcel dat tomu BTRFS este sancu. Ja osobne by som sa akemukolvek RAID s tymito diskami skor vyhol, kedze momentalne v podstate vsetky implementacie (vratane HW raid) nepocitaju s tak kolisavym vykonom.
místo toho bys měl mít u článku tlačítko Flattr
Jeden už mám měsíc, dnes jsem objednal druhý, za měsíc objednám třetí a půjdou do softwarového RAID 5 (zda natrvalo uvidím podle chování). Klidně ti pak otevřu vzdálený přístup.
Suhlas, perfektne citanie, nove informacie a to sa mne nestava casto ze po precitani clanku na IT portali som sokovany novymi informaciami.
To ze vyslo nejake nove GPU nVidia 1080 ci AMD Polaris je sice nova info, ale na tom ma nic nesokuje ... lebo jednak o tom clovek cita uz mesiace a jednak sa to dalo cakat ..., ale tak pekna nazvime to "recenzia" 8 TB Seagate Archive (a technologie SMR vseobecne) sa cakat nedala, zvlast ked vela ludi koketuje s myslienkou kupit ho miesto velkeho mnozstva 2 TB a 3 TB tehiel co maju doma).
TAKTO MA VYZERAT CLANOK HODNY deep in IT, nove info vo vhodnu dobu (lebo napr. v roku 2018 by uz asi fakty v clanku moc nove info nebolo ze ano:)
Uff, dlouhé ale perfektní. S disky postavených na SMR jsem se zatím nesetkal, ale už po prvním průzkumu propadu zápisu jsem tušil, že se to tak chovat bude.
V případě drive-managed je to jemně SSDčkoidní, přeci jen na FLASH paměti zapisuje taky po blocích i kvůli změně jediného bitu. Pak je logické, že pokud mu budeme sypat náhodné celky dat o konstantní délce, tak po vyčerpání volných zón dojde na dobu temna. Řešením je poté jedině předžejkání povahy dat pomocí OS a následný zápis ve formě, která se bude co nejvíce blížit sekvenčnímu zápisu.
Ostatně, ty disky to o sobě hlásají (archive) a tak bych se k tomu choval spíše jak k páskám. Tzn. zapsat a ideálně pouze přepisovat (sekvenčně). Tedy takový mirror většího množství dat, třeba každé 3 měsíce.
Na co jsem ale zvědavej, až si to nějakej blbec koupí (však to má super poměr cena/množství) a bude od toho očekávat stejné vlastnosti. Jak se disk odmlčí, tak se to bude snažit vyreklamovat, protože o tom kulový ví (schválně jsem juknul na zelenou mrchu a BFU nemá šanci objevit, že tohle nebude stejné jako ostatní disky).
Vubec by me neprekvapilo, kdyby v sobe mel firmware statistiky a metriky, ktere pomoci nejakeho toolu vyrobce prozradi jaky bych pomer nahodneho a sekvencniho zapisu a jestli je to jeste v mezich povolenych vyrobcem. Stejne v tom bude zavreny nejaky hodne sofistikovany RTOS na docela vykonem CPU, takze pocitat bokem statistiky nad ramec SMARTu musi byt hracka.
Přinejmenším množství zapsaných a přečtených dat si pamatují a informaci, zda byl překročen zárukou daný workload, umí SeaTools u konkrétně tohoto disku zobrazit.
Díky za vskutku a doslovně DIIT článek!! To za prvé, protože takových "výzkumných" článků není nikdy dost a věřím, že musel dát spoustu práce a doslova sežrat moře času.
Osobně přidám několik postřehů:
1. SMR moc nevěřím, ta představa, že STAMEGABAJTY dat jsou neustále přeskládávány přes nějakou interní cache (která může taky vypovědět službu, nebo zachybovat, např. kvůli hitu vysoce nabité částice) je ještě horší, než představa TLC SSD, které přesypává data v daleko menším rozsahu.
2. použití SMR disku v RAID1 (cokoli složitějšího, zahrnujícího striping, zcela určitě ne) bych se bál taky, přestože moderní RAID řadiče jsou už dnes schopny hrát i s disky s vadnými sektory (což v byl v dobách U320 SCSI jednoznačný důvod pro ententýky-dvašpalíky-typoletíšzkolaven), ale určitě bych neočekával, že v nějakém konečném čase budou fyzické "obrazy" obou disků totožné. Zcela určitě zaúřaduje elektronika a bude vylučovat z provozu slabé a vadné sektory (v tomto případě možná i celé ty megabajtové bloky), a tedy bych (opět v konečném čase) neočekával, že zápis na tyto disky bude trvat stejný čas. A tady je to už otázka, jak se k "výpadku" postaví řadič. Je dost možné, že např. linuxový softwarový mdraid s tím problém mít nebude (zvláště s jádrem podporujícím SMR HDD), ale ruku do ohně bych za to nedal. Zcela určitě by dlouhodobé uživání SMR HDD v RAID1 bylo krásné téma na článek, ale jsem realista. :-))
SMR disky mohou být zajímavé se souborovými systémy typu copy-on-write, jakými jsou třeba btrfs nebo zfs. Oba zmíněné navíc obsahují kontrolní součty dat, takže při zrcadlení souborového systému přes dva SMR disky bych se o integritu dat až tak neobával. Chování SMR HDD s COWFS by taktéž bylo hezké téma na článek, ale jsem rovněž realista. ;-)
------------ ------------ ------------ ------------ ------------
1A) to myslis neco na sposob zabludeny proton, pozitron a ina haved so Slnka? To sa musis bat VZDY A VSADE: normalne HDD, SDD a dokonca aj pri RAM bez ECC !!! Takato "casticova" chybovost je ale este menej ako deklarovanych 1 : 10^15, teda ak by si mal tych 8-10 TB diskov tucet kusov, jeden bit (a tym padom aj bajt) by bol zapisany zle (neviem za aky cas a na kolky pokus).
1B) nech si ne-sindelova niekolko gigova PMR cache zapisuje - a co ma byt? Dnes sa bezne vyrabaju TLC SSD, ktore maju tiez 3-4-5% svojej kapacity ako SLC cache a to ta netrapi? Mna osobne viac trapi SLC cache TLC SSD ako PMR cache SMR HDD, ponivac v pripade toho SSDcka sa ta cache neda prepisat kvadralion-krat !!!
2) aj RAID1 sa da obist nejakym naschedulovanym BATacikom s xcopy commandami, vyhoda je potom absolutne separatne a nezavisle disky ...
------------ ------------ ------------ ------------ ------------
tady se ale hraje o statistické veličiny, problém je právě v tom, že jeden disk ty data bude "přesypávat" prakticky neustále a přiblíží se tak enterprise systémům, přičemž jde "jen" o domácí/cold storage.
nuz treba co najviac eliminovat nahodne zapisy, proste tam nasoukat tie 10-15 gigove mkvcka, ktore sa nemenia, nech to tam lezi :))))))))
Znamená to, že pri plánovanom používaní tohto SMR HDD ako zálohovacieho média (filmy, hudba, obrazy systémových diskov iných PC v domácnosti) je pri zapísaní takmer plnej kapacity nutné disk sformátovať pred začatím zápisu novej kópie už existujúceho súboru, napr. toho IMG sys.partície z iného počítača?
Heeeeee? Nutnost (co i len prakticka) formatovat 8 TB disk by aj pri uvedenej situacii bola fakt divna ne?
Pr. disk naplneny na 7980 GB a volnych z tych 8001,5 GB je teda iba 21,5 GB. Mam tam uz ale 100 GB nekomprimovany image. No tak ho proste prepisem ne? Resp. pre istotu predtym zmazem (nachvilu bude volnych 121,5 GB) a skopirujem tam novsiu verziu suboru.
Preco by som musel formatovat cely 8 TB disk?
Zle som sa vyjadril. Ja viem, ze formatovanie nie je nevyhnutne pri zaplneni kapacity HDD na 100%. Ale kedze ten disk je drive-managed tak pri prepise resp. zmazani a novom zapise toho isteho suboru (100 GB image) si musi interne "poupratovat data", kedze nema ponatia o pouzitom suborovom systeme (NTFS v mojom pripade). Cize je mozne ocakavat, ze ten prepis 100GB na zaplnenom disku zaberie aj niekolko hodin, je tak?
Pri sekvencnom zapise velkych suborov si nemusi z titulu SMR rezie nic upratovat. Proste to sekvencne laduje do SMR zon. Upratovanie SMR zon moze vzniknut nasledne az sekundarne, ako vedlajsi a nezelany efekt defragmentacie. Proste ked ten 100 GB subor bude zapisovat tak, ze bude rozframforcovany na 5000 casti, tak pri najhorsom scenari (ze kazdy fragment zapisuje do inej SMR zony) musi defacto prepisat 5000 SMR zon, ze je brutus 5000x128 MiB = zapisat az 671 GB.
Take moc dekuji za clanek, ze ktereho jsem se zde zase po dlouhe dobe dozvedel neco zajimaveho a duleziteho.
Přidávám se s díky za sofistikovaný rozbor i vysvětlení všech důsledků SMR.
Mám už dva stejné kousky a ze začátku jsem taky nechápavě koukal na čísla z prvních testů. Konečně už trochu rozumím proč se to takto chová, nicméně jako skladovací disk naprostá spokojenost.
Ohledně spolehlivosti u mě jede na ZFS a za 8 měsíců ani jedna chybka.
*** TAKTO MÁ VYPADAT UKÁZKOVÁ RECENZE ***
Ano, super článek WIFTe, díky za něj. Přečetl jsem jedním dechem. Ani by mi nevadilo, kdyby tu nebyly ty různé blogísky, tendenční články na zakládání flejmů a bez rozmyslu přebírané novinky, ale jednou za čtvrt roku takovéto zajímavé téma.
V zásadě souhlas, ale musíte si uvědomit, že bez těch každodenních příspěvků by tento web (a i každý jiný) umřel.
No díky nim ale tenhle web právě upadá. Jediný, kdo tu píše dobré články a recenze je externista WIFT, což je smutný fakt. A jak je vidět, nemusí to být mainstreamové recenze typu nový broadwell-e, nové grafiky (bylo by to fajn, ale chápu, že kvůli těm tendenčním článku diitu nikdo nic nepůjčí :)), na druhou stranu několik článku o tom, kterak jsem si koupil malé SSD, nebo nepotřebuju upgradovat, nebo že nejsem socka na tenhle web nepatří a můžou si být klidně označeny třeba jako blog..
Z toho článku o malém SSD jsi nejspíš četl jenom diskusi, protože to důležité Ti uniklo. David nepsal o tom, že potřebuje nutně co nejmenší SSD (to byla jen omáčka). Psal o tom, že SSD s malou kapacitou se nevyplatí kupovat, protože jsou pomalé.
Super clanok hodny DIIT! Kedze sa to citatelom paci, davam link na este vacsiu hackerinu :) http://spritesmods.com/?art=hddhack&page=1
jsem rád že jsem to nakonec nekoupil. za něco pod 9000 seženete klasický 8tb disk
Akurat 8 TB je asi hranica, kde nejsu ziadne asistencne technologie (SMR, helium ci v buducnosti HAMR). Dalej by bolo zaujimave zistit, ake % 8 TB diskov na trhu su ciste PMR bez akychkolvek asistencnych technologii a ake % 8 TB diskov su "pošpinené" nejakou asistencnou technologiou typu SMR alebo helium. O 10 TB a cistom PMR nema zmysel uvazovat, kedze vsetko od 10 TB vyssie uz bude mat nejake asistencne technologie.
Hélium bych osobně nepovažoval za „asistencnu technologiu“. Myslím, že doba životnosti héliových disků bude srovnatelná s běžnými disky a mimoto hélium nemá vliv na výkon disku v tom smyslu jako SMR. SMR je prostě nový způsob zápisu a je imho trošku škoda, že se aspoň neobjevily rovnou host-aware disky a prodávají se tyhle drive-managed, kde nemá OS šanci zjistit, jak to tam je zařízené.
Nanejvýš by se dalo nějakou analyzační metodou (spolu s pokus/omyl) zjistit, jak je který drive-managed SMR disk fyzicky nakonfigurován a spáchat databázi, podle které by se potenciálně nějaký filter-driver řídil (choval by se k tomu jako k host-aware, akorát by byl aware-db-based. Pak by ale nebyl problém skutečně ty zápisy optimalizovat tak, aby se co nejvíc zapisovalo sekvenčně a pokud možno vždy přes celou zónu.
Imho je to tak, že s těmi host-aware a speciálně pak host-managed disky se musí pracovat tak, že už při rozvržení zápisu se musí eliminovat jakákoli fragmentace, protože ať je to jak je to, fyzický sektor (nejmenší v kuse zapisovatelný fragment) má na takovém disku v podstatě 256 MiB a ne 512 B či 4 KiB jako doposud.
"fyzický sektor (nejmenší v kuse zapisovatelný fragment) má na takovém disku v podstatě 256 MiB a ne 512 B či 4 KiB jako doposud."
Pak by nebylo od veci naucit filesystem 256 MB sektory a OS by se mel naucit ukladat jednotlivy soubory "blokove" prave v teto velikosti.
Technicky vzato něco na ten způsob se budou muset systémy naučit právě kvůli host-managed SMR diskům. Akorát to bude komplikovanější (a zároveň užitečnější) v tom, že systém pak bude moci do každé zóny zapisovat i menší dávky dat, nebude ji muset zaplňovat celou. Jen si pak musí ohlídat, aby když do ní bude chtít data přidat, věděl, kam to má udělat (tam, kde naposledy skončil)
Prostě něco jako „co zóna, to malé 256MiB CD-RW médium" ;). Můžeme přidávat data, ale jak chceme zapsat něco tam, kde už je něco zapsáno, musíme smazat, nebo umazávat od konce (posunovat write-pointer). Tohle bych si dovolil připodobnit k funkci "CD-RW Audio Track Edit" staré dobré Yamahy F1 ;) (ta uměla taky na CD-RW umazat poslední stopu a připsat další). Pak bude nejmenší zapisovatelná jednotka opět 4 KiB (pomíjím, že sektor pak může mít i trošku jinou velikost, o ždibec větší než 4 KiB).
Ano helium neovplyvnuje sposob zapisu ako SMR. Dokonca rozdiel medzi SMR a PMR (samozrejme ze SMR nam PRM nadalej vyuziva a stavia na nom, nenahradza ho) je vacsi ako pred vyse dekadou nastup PMR vs. LMR. Pri prechode PMR na LMR sa nemuseli riesit tie veci co pri prechode PMR na SMR, proste iba stupala kapacita a o nicom inom ako drive-managed nemalo zmysel ani len uvazovat, pretoze OS je uplne jedno ci ma disk LMR alebo PMR zapisom a ani len netusi nejaky rozdiel medzi nimi. SMR je preto najvacsia zmena v sposobe zapisu na HDD za viac ako dekadu.
Druha zmena (ktoru bolo mozne postrehnut z hladiska funkcnosti/rychlosti systemu) bol prichod AF, co pri starsich systemoch mohlo sposobovat problemy s bootovanim (nezarovnane 512 B a 4096 B sektory) ale vyrobcovia HDD vydali na to ficury. Ale co sa tyka dopadu na pouzivatela, SMR je kral v dopade ako to v systeme bude fungovat. Ked si niekto na ten 8 TB disk zacne ladovat gigabajty fotiek s velkostou 3-4 MB (alebo nedaj kriste boze este mensich suborov), velmi skoro bude prekvapkany ... a na druhy den to ponese reklamovat ze "to co ma znamenat" ...
Pri tom heliu sa len clovek jaksik boji ze to vyprcha a HDD je v cudu lebo so vzduchom by nefungoval. Helium je kurevsky prefikane, prenikne vsade a odvsadial. Napr. aj cez steny HERMETICKY UZAVRETEHO balonika. Nieco ako roky ci mesiace nafuknuty a hermeticky uzavrety heliovy balonok neexistuje. Treba dufat ze to soudruzi inzinieri vymysleli tak, ze tam to helium v disku vydrzi aspon 10 rokov.
Kdyby hélium bylo schopné proniknout všude, asi by se nedalo uchovávat ;). Já bych se toho nebál. On mimochodem ten balónek neudrží věčně ani vzduch. On totiž až tak úplně hermeticky uzavřený není ;).
O těch 10 let bych asi strach neměl. A moderní disky stejně o moc déle nevydrží. Poslední dobou mi rukama prochází běžné 250GB, 500GB, 750GB a 1TB disky, které chcípají po 5 letech.
myslel som to tak, ze to prenikne cez steny balona (helium netvori ziadne molekuly, je to inertny plyn, jediny atom He, tak pri predierani sa von nema problem, navyse mu k tomu dopomaha jeho chemicka inertnost a velkost atomu - ono sa proste cez tie molekularne struktury predere von jak nejaka specialna molekula zluceniny z/do bunky cez specialny kanal v semipermeabilnej membrane, helium ale ziadne membrany nepotrebuje), uchovavat sa da, samozrejme nie v baloniku
Skvělý článek, díky. Takhle pěkný už jsem opravdu dlouho nečetl. Problematika těchto disků je zajímavá. Asi bych do toho nešel. Naštěstí archiv internetu nepotřebuji :-)
Povedeny clanek !
Nejuzitecnejsi informace je - 12GB hranice objemu nahodnych zapisu a ~12+ hod. na jejich uklizeni.
Jak by se to chovalo v domacim pouziti - cert vi. Zavisi to typu FS (EXT4, BRTFS, NTFS), jestli to treba umi konsolidaci dat - bylo by dobre vyzkouset, prepisovat LBA 2GB cyklicky. Pokud se 12GB hranice nenaplni, bylo by to skvele a byl bych o SMR ochoten uvazovat. Jestli to ale otrocky jen zapisuje sekvencne vsechny zapisy.. Jenom udrzba i-node nebo last access time na NTFS vygeneruje dost malych zapisu...
Takze - namet na rozsirenou recenzi mas, jak se se mnou spojit - take vis.
Take jsem byl v datove tisni a stejne "zoufale" jsem se snazil pochopit opravdove limity SMR a nasel jsem tak malo informaci, ze jsem, hodnotim-li zpetne po precteni WIFTovy recenze, resil WD-RED 6TB.
Se Seagate mam smisenou zkusenost, ale jeden aspekt dulezity pro domaci NAS - tichost HDD vzdy byl lepsi WD. Sveho casu Samsungy byly taktez vynikajici.
Nedovolim si nepripomenout - RAID neni zaloha. RAID je featura na zvyseni dostupnosti (uptime).
Tezko si dovedu predstavit situaci, kdy bych uprednostnil RAID pred zalohou pri domacim provozu.
Stejne tak si tezko dovedu predstavit duvod proc provozovat fileserver na Windows, zejmena pri dnesnim vyberu komernich NAS nebo barebone a projektu typu freenas.org
Porizeni NAS pred mnoha lety byl nejepsi krok k bezpecnosti dat (geo redundance) a hlavne k jednoduchosti pristupu k datum z ruznych zarizeni.
„…bylo by dobre vyzkouset, prepisovat LBA 2GB cyklicky. Pokud se 12GB hranice nenaplni, bylo by to skvele a byl bych o SMR ochoten uvazovat. Jestli to ale otrocky jen zapisuje sekvencne vsechny zapisy…“
Kdybych se trefil tak, že začátek toho přepisovaného bloku bude přesně začínat v jedné zóně, tak je to imho OK. Když se trefím vedle (což je výrazně pravděpodobnější), tak se imho "nesekvenčně" (tj. na tu cache oblast) bude po každých 2 GiB zapisovat přečuhující začátek (konec asi taky, protože to je drive-managed disk, který prostě počítá s tím, že všude jsou data, takže vyhodnotí-li, že dávka dat není zarovnaná na zónu, bude ji tlačit do cache oblasti).
No, a až těchdle „zbytků“ nasbírá ~12 giga, tak začne tóčo :). Teoreticky, pokud se trefím mimo zónu (a předpokládám 256MiB zóny), se při každém přepisu té 2GiB testované oblasti zapíše 256 MiB do cache oblasti (a je asi jedno, jak moc se netrefím, protože to pokaždý bude 256 MiB). Takže dejme tomu, že tu hypotetickou 12GiB cache zónu zaplním po zápisu víc jak půl tera (přesněji 576 GiB) do té testované cyklické 12GiB oblasti.
Mám tyhle 2, starší už skoro rok. Používám dle názvu (na archivaci), takže super a nic oproti jiným HDD nepoznám.
Mám jen 2 poznámky:
1) disk nemá prostřední boční otvory na šroubky, jen ty krajní. A to mám snad ve všech skříních a šuplících montování 3,5" disků na prostřední + jeden boční.... nepříjemné :-(
2) Asi před týdnem u nás tento disk skokově zdražil o tisícovku. V zahraničí ale vidím pořád stejné ceny, tak předpokládám, že až třeba dorazí do republiky nová zásilka, tak se to vrátí. Doufám.
Velice pekna a poucna recenze, dekuji.. Alespon vim na co se zamerit, az mi budou volat znami (co se x let neozvali), ze jim vytuhava jejich novy pocitac (s jehoz vyberem kompoment se zamozrejme neporadili) a ze nevi co s tim.. :)
Díky WIFTe. Je to ještě horší než jsem si myslel. Ale díky tobě jsem připraven a nebudu překvapen. A nebudu se divit tomu jako prase blesku co s tím jééééé.
Super recenze ;)
ja to psal puvodne na G+ ale zopaknu to tu v kratkosit, zkusil jsem do domaci NAS ds1815+ vzit 3 tyhle Seagaty a byl to naprostej pruser. Neslo to pouzit, bylo to extremne pomale, v podstate cela NASka dost lagovala a prenosy byly kolem 15-20mpbs ... dva se mi povedlo vratit a jeden mam b pocitaci pod truecryptem ;) tak uvidime co se s nim casem stane. Jinak po vymene za WD Red NASware rychlost standartni ja jednom gigovem kabelu 95-105mbps a hlavne zadne divne lagy
MAK
prosim napiste mi niekto priklad realnej aplikacie, ktora zapisuje 12GB nahodnych dat za 2minuty.
neviem si predstavit, ze by som doma nieco take robil
Třeba instalace Windows + vsech aktualizaci, k tomu par aplikaci, např. instalace Android Studia Vám na disk nahraje spoustu malých souborů, čili bude se jednat prakticky o náhodný zápis. Sice nebude to za 2 minuty, ale výsledek nakonec bude stejny
Ale pokial budu tie tisice malych suborov v ramci jedneho "bandu", problem by to nemusel byt... Neviem.
Není. Právě před pár dny jsem na tento disk sypal cca 1 600 000 malých souborů (od pár kB po desítky MB) a zpomalení se neprojevilo. Samozřejmě NTFS bitmapa byla čistá a nové soubory se tak sypaly plusmínus sekvenčně za sebe.
Přestože ve výsledku bude obsah souborů uložený sekvenčně za sebou, neznamená to, že disk bude provádět pouze sekvenční zápis obsahu souborů. Kromě samotných dat je třeba taky aktualizovat metadata, transakční log a buhví co ještě. Nestudoval jsem jak přesně funguje zápis souboru, ale předpokládám, že ve chvíli, kdy aplikace oznámí systému, že ukončila práci se souborem, operační systém vysype všechna změněná data související se souborem na disk, čili provede změnu na několika místech disku, ve výsledku tedy ukládání mnoha malých souborů bude dost podobné náhodnému zápisu.
Ano, obojí se aktualizuje, ale to není patologický jev, to je standardní vlastnost souborových systémů vůči které se dá docela snadno optimalizovat. Má osobní empirická zkušenost to potvrzuje, protože jsem žádné zpomalení nezaznamenal.
Přidání záznamů do MFT je mnohokrát opakovaný zapis do stejného clusteru (než se přejde na další), který se rozhodně stíhá aktualizovat v tom vyrovnávacím bloku disku. Na NTFS mívá souborový záznam typicky 1024 bajtů, což je i při mém workloadu jen 1,5 GB, tedy jen malá část té 16 GB zóny, a tu může disk popřeskládat v klídku až po dokončení všeho souvislého kopírování. Nakonec i ty nové části MFT se vytváří souvisle, tak není třeba číst a přepisovat tolik zón.
Podla mna staci bezne fragmentovany FS a zacat tam strihat/reenkodovat nejake 4k video. V blizkej dobe celkom pravdepodobny scenar.
Ale tu ide hlavne o to, aby sa o tejto moznosti vedelo. Aj SSD ma krute limity, ale dosiahnut ich "beznym pouzivanim" nie je celkom jednoduche :)
Úplne postačuje, aby tam tých 12GB dát dal za menej ako 12hodín a už je to asi pocítiteľné.
Kdyz uz to ty nahodny data zapise sekvencne jako SSD, tak proc to tak nenecha ulozeny a jen nezdeli OS kde data jsou, stejne tak jak to dela firmware SSD.
Mozno preto, ze by bolo treba velky overhead na ukladanie tychto informacii a hlavne by sa nedal urobit defrag a nasledne ak by si chcel ukladat nejaky velky subor, tak by ho fragmentovalo... Treba sa na tento disk pozerat v kontexte jeho urcenia.
linux fragmentuje pri zapise na disk zamerne, ma to ako ficuru
Cca pre 2 mesici jsem upgradoval "NAS" a koupil jsem 8ks techto disku. Jsou pripojene na radic v HBA modu a je na nich ZFS (raidz2). Hned na zacatku jsem na ten pool presypal cca 6TB dat z puvodniho poolu (8x2TB raidz2). Tahal jsem to pres rsync po 1Gbps a rychlost byla celou dobu lehce nad 100MB/s. Cca 80% dat byly velke soubory (>500MB) a zbytek male veci jako fotky, dokumenty, zalohy z webserveru atd. Nezpozoroval jsem absolutne zadne problemy s rychlosti a ani zadnou aktivitu disku po dokonceni kopirovani. Jednou za tyden spoustim scrub a ten jede cca 560MB/s, do ted absolutne zadny problem. Ten ZFS pool pouzivam na zalohy velkych souboru (500MB+). Na zalohy malych veci pouzivam ten druhy pool (8x2TB raidz2).
Takze pokud se ty disky pouzijou opravdu jako Archive a pocty nahodnych zapisu jsou minimalni, tak v te technologii nevidim problem. Je treba vedet, jak bude uloziste pouzivano. Ale rozhodne bych se vyvaroval pouzivat ty disky v HW RAIDu. Tam by je radic temer jiste z RAIDu vyhazovat kvuli tem timeoutum.
inak prve co ma napadlo pri tom rychlom nahodnom zapise. ze tento disk ma nejaky druh SandForce radica
:DDDD Jsem se už lekl ,že to nikdo nevzpomene ... Aneb máte super nové extrémně rychlé SSD ... které má jen tu "vlastnost" , že čas od času se celý systém zastaví na pár minut a můžete si skočit na kafe .....:DDDDD.
V každém případě dobrý pocit ze SMR nemám a beru to jako solidní podraz na uživatele očekávajícího výkon klasických disků . Pro mne osobně je jakýkoli přínos SMR na úrovni někdejší "komprimace disku " - což v praxi taky bylo dost dobře nanic ...
Jen technicka: "nekdejsi komprimace disku" nahodou fungovala bezvadne. Ja pouzival na XTcku a na 286 program Stacker a musim rict zcela bez ironie, ze na 20MB HDD to nacpalo tak 35-40MB dat. Pricemz nebylo znat nejake zasadni zpomaleni.
Znam I lidi, co pak pouzivali DoubleSpace od Microsoftu a fungovalo jim to taky v pohode.
Stejně jako někdejší komprese disku nebyla ani náhodou na nic, tak ani SMR není podraz. Disk se jmenuje Archive, je určený na archivování dat. Kdo u něj očekává chování jako u desktopových disků je pitomec. Ve stejných kapacitách nabízí Seagate disky pro desktopové i enterprise nasazení, nečekaně pojmenované Desktop a Enterprise, které budou mít určitě zcela jiné provozní charakteristiky.
Tyhle se mi rozbily už dva. Třetí, co mi přišel z reklamace, jsem raději rovnou prodal. Mám i 5TB variantu, ta běží spolehlivě, klep klep klep! :))
Jen dvě věci:
a) jsem zatraceně rád, že jsi kecal, WIFTE, když jsi před časem psal o konci psaní a stažení se z DIIT (mimo občasného ublognutí si, když čas dovolí)
b) jelikož tuhle stať nazýváš "malou uživatelskou recenzí", buď tak hodný a až se vytasíš s něčím větším, dej avízo předem, ať si v práci můžu nahlásit dovolenou - mám rád u čtení klid.
No a jinak dík za článek (jak je u Tebe zvykem) s vysokou přidanou hodnotou!
BRAVO!
Perfektní článek, co se čte jako detektivka. Muselo to stát fůru práce a zabrat děsného času. Respect!
Děkuji za perfektní článek. Přesně tohle mi na vašich serverech chybí, připomíná mi to staré dobré časy.
Na Diit.cz si občas ještě něco vyberu, ale z cdr.cz se stal legitimní herní server, stříknutý občasnou astronomickou zajímavostí.
Dva tyhle disky používám už cca 3/4 roku k plné spokojenosti jako skladiště filmů a seriálů. S rychlostí zápisů problém není (zpravidla se drží někde pod 100MB/s, někdy při větším množství zapisovaných dat spadne dočasně na cca 30MB/s, tedy nic co by pro dané použití jakkoliv vadilo), a to i přesto že jsem stylem "smažu pár set GB starých dat a zapíšu místo nich pár set GB nových" je už přepsal několikrát dokola.
Když jsem chtěl ale přikoupit třetí disk, musel jsem ho vždy vyreklamovat (celkem už 3 disky), protože se jim ani neroztočily plotny (hned od prvního zapojení). Tak nevím, jestli to je nějaká nepovedená série (všechny ty 3 vadné disky byly s firmware AR17, ty starší funkční mají AR13 a AR15) nebo jsem měl jen nehoráznou smůlu na špatné kusy. Má někdo podobnou zkušenost?
Celkem pochybuji o názvu "Archive HDD". Podle mého magnetický záznam ve srovnání s optickými disky degraduje více a rychleji. Navíc zde na tomto disku je hustota obrovská. A co teprve degradace komplikované mechaniky a elektroniky. Copak to asi udělá po 30 letech bez zapojení? Nevěřil bych tomu názvu ani za mák. Ale na běžné přehrávání filmů a hudby to může být vhodná věc!
No po 30 letech bez připojení na něm samozřejmě nic nebude, to už nejspíš ani po 5 letech. Ale úplně stejně jsem po 10 letech nedostal data z disků s mnoha-řádově nižšími hustotami (např.: 1,2 GB disk). HDD i SSD je nutné jednou za čas připojit, zapnout a nechat pár dní v idle aby elektronika mohla zkontrolovat a občerstvit slábnoucí záznam nebo náboj v buňkách.
Nemyslím. Mám starý G3 Mac s originálním 20 GB IBM diskem a dodnes je v pohodě (rok 1999). Pochopitelně řada dat se měnila, ale třeba OS tam už tam je nezměněn tak cca 14 let, MBR bude originální z první instalace. Žádné chyby čtení nevykazuje. Staré video kazety či audiokazety také bývají funkční, u nich spíše mechanicky degraduje pásek.
HDD povětšinou odejdou dříve mechanicky než že vyšeptá magnetická hysterze. Takže si myslím, že po 30 letech to bude normálně čitelná plotna, problém bych spíše viděl v ložiskách případně oxidace v drobné elektrinice.
Neporozuměli jsme si. Moderní disky provádí při čtení i průběžně (v idle) všelijaké fitness testy. Jde i o kontroly kvality zápisu, např. nakolik jsou zapsaná data opravitelná nebo zda je magnetický záznam v limitech určitosti. Blíží-li se to problematickým hladinám, elektronika může rozhodnout sektor znovu zapsat a záznam tak občerstvit. Uživatel to ani nepostřehne.
Nevím jak často se to musí dít, to je obchodní tajemství každého výrobce, ale vím z vlastní zkušenosti, že více než pár let vypnutý disk bývá problém.
Nevíte někdo, co se o víkendu stalo s cenami? Podle Heuréky se minimální cena zvedla z 6000 na 6550 (a to jen u jednoho naprosto nedůvěryhodného obchůdku, reálná minimální cena je 7180), průměrná cena pak z 6500 na 7500. Co způsobilo skokové zdražení o 20%?
No to by mě taky zajímalo, takhle si na ten druhý kousek ještě počkám.
Recenze od WIFTa? :)
WIFTe - nemohl bys udelat testy tohoto druhu:
- zapis DVD ISO obrazu: while(1) { zapis(4.7G soubor) } (nebo brripy, mkv)
- zapis DNG sekvence: while(1) { zapis(12MB soubor) } (ekvivalent treba RAW fotek)
Ono to jsou totiz jediny rozumny workload, ktery vyzaduje obrovske kapacity. Zajimalo by me, po jake dobe ten disk vyplytva cache - protoze jakmile to nema ram vetsi nez je velikost zony, tak nechapu jak muze vedet co je a co neni souvisly zapis.
Btw pred vice nez rokem jsem byl v kontaktu s clovek ze SGT ohledne archive rady:
- "The archive label is still a bit vague, being better defined by "not for OS drives" at this point."
- "SMR introduces a new requirement for HDDs: forward-write only."
Nevim zda jeho prace byla jiz zaclenena do mainline, delal toto: https://github.com/Seagate/SMR_FS-EXT4
Disk vzdy vi jak velky soubor bude zapisovat. Kdyz zahajite kopirovani 20GB souboru tak se na hdd alokuje toto misto. Muzete si to klidne vyzkouset, dejte kopirovat velky soubor a natvrdo v prubehu vypnete pocitac ze site (bez UPS) po zapnuti najdete soubor o cilove velikosti avsak data v nem budou jen do vypadku. Podobny to bylo u vypalovani CD ktere se nedopalilo.
To disk tedy nevi ani nahodou! Nektere filesystemy maji 'pre-allocation', ale to opravdu neni pravda vsude. A i pri alokaci predem, nemusi platit ze ten soubor bude nahran do jedne souvisle oblasti na disku..
To by musel pevný disk rozumět struktuře souborového systému, což není v jeho moci (znát každý souborový systém).
Ano, to jsem tam nezminil, vzdy to tomu disku musi sdelit OS pomoci filesystemu.
„jakmile to nema ram vetsi nez je velikost zony, tak nechapu jak muze vedet co je a co neni souvisly zapis.“
Ugh, to je hodně dobrej postřeh. Každopádně nějak to poznat musel, když HD-Tach RW prošel celej.
Scénář 1 by se dal vymyslet i v praxi, to by asi nebyl problém (jen by to nebylo while(1), ale prostě nějaká sada velkých souborů). Ostatně to se chystám udělat. Jen budu muset vyndat disky ze serveru a strčit je do test stroje s tím 8TB diskem (přes síť to tahat nechci ;).
A se scénářem 2 by se taky asi dalo něco dělat. On by samozřejmě nebyl problém říct IOMeteru "dělej souvislé 12MB zápisy), ale budou tam chybět ty záznamy do tabulky souborů ;).
nevim zda to chapu dobre, ale myslim, ze pro disk neni problem si drzet historii adres bloku, do kterych se za posledni treba minutu zapisovalo, to bude zabirat pak kB v nejake pameti. Pokud ty adresy jdou sekvecne, je to sekvencni zapis, pokud ne, tak neni. priklad prichazejicih requestu zapisu do bloku: 10023, 10024, 10025 atd...toto je sekvencni zapis. naopak toto: 10366, 251, 2318121, 521 zcela jiste neni :)
Jak bych to udělal já.
Dejme tomu, že buffer je 128 MB a zóna 256 MB. Zásadní otázkou je, kolik mega dat se „zničí“ přepisem jedné SMR stopy (pokud nejde o tu poslední, potažmo několik posledních, pokud se jich zničí víc jak jedna). Rozhodně to musí být značně méně, než jak velký je buffer. Dejme tomu, že to je 32 MB (může to být víc, ale možná i míň, fakt nevím, třeba někoho z vás napadne, jak to odhadnout - známe jen počet zón, ale ne počet stop na zónu, to bude beztak variabilní, protože každá zóna obsahuje stejné množství dat, tím pádem čím víc blíže ke středu disku, tím více stop na zónu).
Budu předpokládat, že přepisem jedné stopy se dá zničit až 32 MB dat. Takže dostávám data v sekvenčním pořadí (dle LBA) a zapisuji si je do bufferu (128MB). Jakmile mám 64 MB takovýchto sekvenčních dat, mohu si dovolit v klidu zapsat přímo do SMR zóny 32 MB. Vím, že tím zničím dalších 32 MB, ale stejně tak vím, že je mám v bufferu a že je pravděpodobně budu v dalším kroku zapisovat.
Pokud dostanu dalších 32 MB sekvenčních dat (to už je třetí 32MB dávka), mohu těch předchozích 32 MB (druhá dávka) zapsat zase rovnou do zóny za těch prvních 32 MB (první dávka), protože platí totéž, co v předchozím případě: zničím tím až 32 MB dat, ale mám je v bufferu a jakmile dostanu další data, mohu tato zachovaná data zapsat.
Pokud ale následně dostanu data, která nejsou pokračováním předchozí sekvence, zapíšu těch "zničených", ale uchovaných 32 MB dat (třetí dávka) do diskové CMR cache a později, až bude klid, zrekonstruuji zbytek zóny načtením nezničeného zbytku zóny a spojením s těmito odloženými daty - zónu jako celek dopíšu od této třetí 32MB dávky až po konec zóny (s ohledem na malý buffer to budu zřejmě dělat navíckrát, ale udělat se to dá).
Je to zjednodušeně napsané, ale princip je asi jasný. Ideální by samozřejmě bylo, kdyby buffer byl větší než zóna, ale dá se to takto podle mě udělat i s bufferem menším než zóna, jen je to pro disk víc práce.
Mě by zajímalo, proč tester zapíše na 8GB disk, který je určen k archivaci 11GB dat a pak se diví že ten disk je přehlcený a nechce se s ním bavit? To mi příjde trošku nelogické až tragické.
V pátek odpoledne jsem mentálně vyčerpán. Pomozte mi, prosím, pochopit tento komentář:
poslední tři odstavce:
http://diit.cz/clanek/recenze-8tb-seagate-archive/zahlceni-disku-do-bezv...
Také nechápu. Nula sem, nula tam?
Super, díky moc za článek, co mi pomohl si udělat představu jak se taková věc chová. Na lifrování archivačních dávek souborů by to teda si fakt mohlo fungovat. Jen tedy, když tahle mrcha chcípne, tak toho s sebou vezme hodně - takové digitální zřícení Airbusu 380.
Napadá mě ještě, že při "tupé obsluze" na Windows by snad i lépe mohl posloužit ExFAT než NTFS, protože moje zkušenost s ExFAT je, že má tendenci skládat data pěkně za sebe a nefragmentovat když to není nutné (na disku je stále místo), na rozdíl od NTFS, který to "blbec" vždycky rozpráší všude v rozsahu oddílu.
Já si skoro říkám, jestli by na to nebyl nejlepší UDF ;) (myslím z toho, co Windows umí), akorát to holt není pro pevné disky ;).
Takže vlastně Windows přemluvit, že to je spíše takové velké přepisovatelné DVD/BD a nikoliv HDD s random přístupem. :-)
Vzdyt to JE takové velké přepisovatelné DVD/BD a nikoliv HDD s random přístupem. Respektive, ne jedno velke ale nekolik desitek tisic mensich.
Mame cca 6 tech techto disku v MD-RAID 6 poli na ktere sypeme jednim vlaknem rsync zalohy a zatim to jiz nekolik mesicu funguje. Pri cteni teto recenze mi trochu behal mraz po zadech, ale doufam ze MD-RAID k nim bude schovivavejsi nez nektere HW RAIDy a nebude je vykopavat z pole kdyz cas od casu zacnou uklizet. Docela by me zajimalo, jak by fungugovaly se ZFS, zejmena v RAIDz-6
Tak me napadlo, ze kdyby se pouzil vhodny filesystem, napr. BtrFS ktery, pokud to chapu dobre, zapisuje vse vice mene sekvencne (copy on write) a temer nikdy nic neprepisuje (je to skutecne tak?), tak by se to mohlo chovat jako bezny disk. Dokaze to nekdo potvrdit? WIFTe, nechces to otestovat? Ted jsem nekde cetl, ze pro ZFS SSD cache neni potreba TRIM, protoze to tam zapisuje vzdy pouze sekvecne (opet metoda copy on write).
Pokud na 8TB disk zapises 6TB dat, potom 4TB smazes a zapises dalsich 6TB, tak musi prepisovat kazdy filesystem. BtrFS nebo ZFS budou urcite vhodnejsi nez "obycejne" filesystemy, ale jako bezny disk se to porad chovat nebude, prinejmensim ne pri vysokem zaplneni.
ano, to urcite, ale prepisuje to vice sekvencne nez bezne filiesystemy, samozrejme pokud ma dostatek volneho mista.
Zajímavé. Koupil jsem externí 4TB 2,5" HDD Seagate ST4000LM016 - podle brutální kapacity a 128MB cache SMR a podobného chování jsem si zatím nevšiml. Ale možná jsem popis špatně pochopil. Kopčil jsem na něj po stovkách GB najednou a že by se po pár GB zahltil a zpomalil, to ne.
Důležité je "po pár GB NÁHODNÝCH zápisů", tedy zápisů nejdoucích kontinuálně blok za blokem, ale zápis typu hoď blok tuhle a blok támhle.
Pouzivam zhruba pol roka bez problemov na file server raid 5 so styrmi tymito diskami na hw radici Adaptec 5405 + 50 GB ssd ako bcache vo writeback mode pred nim. Raid ma suborovy system xfs a mountujem ho s nasledujucimi parametrami: noatime,nodiratime,logbufs=8,logbsize=256k,largeio,inode64,swalloc,allocsize=131072k,nobarrier.
Nahravane su subory v priemernej velkosti zhruba 500 MB, vynimocne sa nejaky zmaze. Drviva vacsina operacii je citanie suborov. Operacny system je nainstalovany na separatne ssd.
ahoj, rád bych doplnil něco málo za sebe :)
poměrně hodně jsem na téma tohohle 8TB macíka napsal sem http://pctforum.tyden.cz/viewtopic.php?f=14&t=237521 a popsal jsem i zvláštní chování při dlouhodobějším torture testingu disku. podle všeho se nakonec ukázalo, že něco hnije u mě na řadiči, protože podobné chování se nakonec objevilo i u jiných disků (s tradičnější PMR technologií), takže SMR je v tom nejspíš nevinně a tipl bych si, že se "někde něco na řadiči" prostě jen časem začne příliš zahřívat.
taky bych rád zdůraznil, že v mém i WIFTově případě se jedná o původní model ST8000AS0002. věc se má tak, že Seagate ve světě už prodává jiný model ST8000AS0022 (ten původní už SGT dokonce ani nemá na webu!), který má novější firmware AR17 - nejen že tento firmware odstraňuje pár dětských nemocí SMR, ale na rozdíl od původního drive-managed modelu se už jedná o host-aware disk.
pro úplnost, existuje i model ST8000AS0012, který je to samé co ST8000AS0002 plus šifrování.
nějaké čtení k tomu:
http://www.computerbase.de/forum/showthread.php?t=1564686&page=4
https://groups.google.com/forum/?hl=en-GB#!topic/bsdmailinglist/VWxHO5jRL1E
zdravim Vas, mam otazku, jaky mate radic? mam par kousku 8TB seagate archive a velice spatne zkusenosti, viz muj jiny prispevek v tehle diskusi, tak jestli to neni treba radicem? diky
Asus P5B Deluxe s modnutým RAID BIOSem a driverem, je v tom tuším ICH8R. V externích řadičích mám nějaký ASMedia, je to Axago PCES-SA.
hard disk sentinel 4,71 pro
Crucial_CT512M550SSD1-Micron 20nm MLC NAND zapisanych dat 45,82 TB stav ssd perfektny. zdravie 93% momentum cache zapnuta ,
ST8000DM002-1YW112 desktop verzia 256mb cch. http://disctech.com/Seagate-ST8000DM002-8TB-SATA-Hard-Drive
po rokoch na starsich hdd je to naozaj uzasny disk, drzi vo vsetkych testoch stabilnu rychlost 240mb/s, teda o nieco viac ako reklamovanych 220. tym sa aj verzia desktop vyznacuje. zaplneny nad 70% stale podla crystaldiskmarku nad 200+ citanie aj zapis. ale este mozem testovat len tak pre zaujmavost. zatial len 3 mesiace provozu. Vyskytlo sa 8 vadných sektorov na tomto pevnom disku. Obsah týchto sektorov bol presunutý do náhradnej oblasti.
V tomto bode nie je možné uplatniť záručnú výmenu disku,s výnimkou situácie, keď zdravie disku neustále klesá.
Odporúčame pravidelnú kontrolu denníka udalostí (logu) disku, kde nájdete prípadne vzniknuté problémy.
problemy "zdravia" a sektorov u jedneho aj druheho disku su sposobne mojou vlastnou vinnou. neocakavane pady systemu z roznych pricin.
som zvedavy kolko vydrzi ten segate 8000 ked ma teraz 92% zdravia, stalo sa to po jednom pade systemu...co je skoda.
Konečně po delší době pořádký článek jako za starého CDR. Díky Wifte.
jak jsem si precetl clanek (po hodne dlouhy dobe zajimavej a autor asi ve volnym case pise detektivky, kdyz dokaze napinat ctenare az dokonce:-) a i diskuzi, dochazim k zaveru, ze tady bych uz videl smysl v pouziti hybridnich disku. Pokud budou 8TB (a vic) sindelove disky jako ne-archivni disky (podle obrazku HAMR a helium nejsou nahradou sindele ale doplnkem), byl bych pro, aby v sobe mely nejakou kapacitu jako SSD (a to vetsi nez 12GB :-). pak bych s dovedl predstavit HD-SSD (12TB-128GB) jako normalni disk.
PS: ja v tom heliu taky vidim problem...
ja som chcel ist do heliovej verze ktora bola vtedy zlacnena(ktovie preco) ale nakoniec som zobral desktop verziu typu ktory pan jezek testoval. pozri si rozdiely v specifikaciach na tom co testoval jezek a v mojom dskt.v.. u hybridov by som vyznam nevidel, ked platnovy dosahuje v priemere 40-50% vykonu toho ssd co som uviedol vyssie. a rychlost kopirovania z ssd na hdd vynikajuca. v raid 0 by som mal mat skoroo rychlost ssd co by bolo pri nenaformatovej kapacite 16TB :-) paradne a deklasujuce ssd v pomere vykon cena (700eu)+-
este dodam ze tieto nove rychle a featurkami vybavene hdd su nutnostou ak chcete vyuzit aj rychle internetove pripojenie . starsie typy hdd proste nestihaju a laguju. aj 1gb net uz dnes nieje raritou pre beznych userov. (100eu)
do nas ov sa hodi ten typ co testoval. na bezne domace zuvanie))
Mne by spíše zajímalo, jakou rozumnou strategii zvolit pro zálohování na více různo-kapacitních disků, chci-li zajistit duplicitu záloh.
Během minulých cca 15 let jsem to řešil tak, aby se veškeré zálohy (všech počítačů/disků) vešly na jeden archivační HDD. HDD do šuplíku, pustit skript, ráno hodit druhý do šuplíku a opět pustit skript. Jeden HDD doma, druhý v práci. Prostě vlastní elektronická stopa na jednom kusu hardware, vezmu a vím, že mám vše.
Jenže tempo se nějak zrychluje, jak členové širší rodiny přecházejí z klasických médií na elektronická. Dnes mi stačí 4 TB disk, ale za nedlouho bych měl opět upgradovat.
Takže se mi tady tak trochu kumulují staré disky. Děsím se hlavně diskotékového přehazování HDD, jejich popisování a ujišťování se, že jsem nějakou část nezapomněl zazálohovat. Mohu "domácnost" rozdělit na nějaké logické celky a k nim přiřadit archivační HDD, ale už to začíná zavánět opruzem...
Tak treba na mensi disky nahravat jen dokumenty a kazdy den a jednou za tyden na vetsi disky vse. Ale nejpohodlnejsi opravdu bude nahrat vse na jeden velky a vymenit.
Dekuji za test a obsahle informace. Presne tyhle o SMR technologii chybely.
Skvela prace!
Dík, to byl super článek, ty informace se budou moc hodit.
zdravim panove, predevsim podekuju WIFT-ovi za recenzi, kez by takovych tady bylo vic :) a pak se podelim o sve zkusenosti. pred cca pul rokem jsem koupil jeden (ne u zeleneho urvaneho MZ, u konkurence byl levnejsi) na zkousku navzdory nekolika negativnim reakcim na rychlost ... rikal jsem si, zkusim, mozna ho pouziju jednou za cas na zalohu a mezitim ho necham lezet za tu cenu za TB. cca pred mesicem jsem si rekl, disk je spolehlivy bezi 24x7, udelam raid5 3+1 na zalohy ... nez jsem se rozhybal, tak jsem zjistil ze pres vikend cena poskocila o necelych 25% tak jsem narychlo koupil u zeleneho urvaneho MZ, kde jeste byla cena puvodni (po par dnech tez zvedli), 3 kousky, jak se za poslednich par tydnu ukazalo byla to mozna obrovska chyba. (mezitim jsem reklamoval 3 kousky z ted celkovych 6 na vadne sektory) a momentalne mam dalsi na ktery rika smart tohle :
smartctl -a /dev/sdd
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.19.0-32-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: /3:0:0:0
Product:
User Capacity: 600 332 565 813 390 450 bytes [600 PB]
Logical block size: 774843950 bytes
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
na druhou stranu kdo by nechtel disk s 600 PB :D
a ted jak k chybe/reklamacim dochazi. 1. po tom co jsem koupil ony 3 kousky, udelal jsem z nich radi5 3+missing, zkopiruju data a pak pridam ten 4. jeden z disku vykazal bad sector v prubehu 24 hodin. 1. reklamace. dalsi jel v poho pri kopirovani, cca 3.6TB dat za cca 20 hodin. ale pak se ukazalo, ze ma bad sector pri tom, jak jsem zaradil 4. disk do raidu 2. reklamace. pri dalsim disku jsem si rikal, ze nejdriv zaplnim kapacitu raid-u a pak uvidim. takze o5 raid5 3+missing a kopirovani do mrte. nejdriv disk hazel chybu uvedenou vyse, ale zadne bad sectors, tak jsem parkrat restartoval, obnovil raid, dal znovu kopirovat vymenil sata kabel, zmenil poradi disku atd.. po nejake dobe i tento disk vykazal vadny sector, takze 3. reklamace. dnes mam o5 disk na reklamaci ... co k tomu rict? nekupovat a uz vubec ne za cenu jakou chteji dnes. rek bych ze lokalni distributor zvedl cenu aby "kompenzoval" velky narust reklamaci ... ted jsem zvedav kdy i ten disk ktery jsem koupil pred pul rokem zacne vykazovat bad sectors. a mozna otazka zni, jestli disk samotny muze fungovat ok, ale s mdraid delaji problem ... mozna kuli tomu, ze kernel neni optimalizovan? i kdyz vadne sectors nejdou na vrub os. to bych ale pripsal na vrub vyrobci, ze je hloupej a stejne jsem presvedcenej, ze SMR je na hovno a uz nikdy vice ... bohuzel me to tahle zkusenost stala temer 20k CZK
Já bych ten disk asi v první řadě nikdy nedával do RAIDu jinýho než mirror (což plánuju právě kvůli tomu, že tomu disku zas ak moc nevěřím).
Jinak těch 600 PB je roztomilých, to by mi asi na nějaký čas vystačilo ;).
U 600PB by mi ani nevadil sindelovy zapis protoze bych nemusel mazat.
Jen pro doplnění - kompletní přepis disku = 10,3 dnů čistého času, možná to bude někoho zajímat.
(dd if=/dev/urandom of=/dev/sde)
Evidentne to nikoho zaujimat nebude, resp. iba "zaujimat", kedze pre NAS a linux je ten disk absolutne nevhodny. Na win81 som limitovanim 50MB/s dosiahol aj realne tuto rychlost (viz. prispevok vyssie, cize asi 44h na zaplnenie 8TB), ale neslo o synteticky test ale realne data, tak to iba odhadujem.
To krapet nekoresponduje s tím, co mi předvedl HD Tach RW. Přepis celého 8TB disku rozhodně netrvá ani jeden celý den.
To je mi jasné, proto tento údaj uvádím. Nezkoumal jsem proč. Server měl průměrné vytížení kolem 1%, v iotop se zápis na disk pohyboval kolem 5-10MB/s. Přitom čtení /dev/urandom rozhodně není nějak náročná akce, zato data nejsou komprimovatelná.
Neuvěřitelné! Takhle detailní, důkladnou a vyčerpávající recenzi jsem naposledy četl před mnoha a mnoha lety v dnes dávno zaniklém časopise Bajt!
Úplně mi do očí vstoupily slzy nostalgie. Tento den si budu navždy pamatovat. Dobrá práce!
p.s. dokonce jsem se kvůli tomuhle komentáři zaregistroval!
Dobrý den, chtěl bych položit dotaz.
Je možné, že by tyto neduhy dokázal vykompenzovat rámeček na HDD a připojení přes USB3 ?
O co se mi jedná ?
Tento HDD mám, naformátován v NTFS a k Win10 jej připojuji přes USB3 v HDD Boxu.
U tohoto HDD mám zaškrtnuto "optimalizace pro rychlé odebrání" tzn, nezapisuje do cache HDD ale do cache systému ! Kopíruji 2Tb dat a disk při přenosu hlásí ve Windows rychlosti v rozmezí 50-100Mb/sec. Po většinu času těch 100 ! Zajímalo by mne tedy jestli se někto setkal i s tímto a zdali i může někdo potvrdit odlišnou funkčnost v tomto "režimu".
Díky !
Chcem len upozornit kazdeho, kto najde tento clanok a tuto diskusiu v suvislosti so Seagate Barracuda Laptop diskami, ze vsetky, ktore su v ponuke (500GB - 5TB) su bez vynimky SMR disky. Vo vlastnostiach diskov sa o tom nedocitate, Seagate samotny tiez pokial mozno o tom mlci. Az na zaklade kritiky, ktora na spolocnsot prisla uvedeni diskov do predaja od IT magazinov danu informaciu zaniesli do svojich User Manualov. Takze bacha, je jasne, ze taky 2TB disk s hrubkou len 7mm je lakava ponuka, ale dan za nu je prave pouzitie SMR namiesto overeneho PMR.
WIFTe, prosím tě, jeden stupidní dotaz. Rozumím tomu správně, že onen testovaný kus 8TB Seagate Archive je bez Hélia? Všechny náznaky tomu odpovídají, ale že bych se to někde konkrétně dočetl se úplně říct nedá... Jednou jsem dokonce pojal podezření, že cokoliv od 5TB+ je s Héliem, jenom to radši přestali zmiňovat, aby neodradili lidi, kteří jsou k této technologii skeptičtí...
Event. dotaz 2: Jak hodnotíš disk po roce fungování, spokojen?
PS: Nemusí to být taková vele-recenze, jen tvé subjektivní pocity po nějaké době a jestli disk plní to, co jsi od něj očekával...
Náhodou jsem sem zabrousil - disk hélium nemá a co se provozu týče, musím říct, že zatím prostě jede, akorát je to teprve tak před půl rokem, kdy jsem ho dával do trvalého nasazení.
Pro ty, co sem zabrousí po době koronavirové: Disk stále jede. Nalítáno má 31,5 tisíce hodin, zapsáno asi 32,5 TiB, přečteno něco přes 41 TiB. Jsem těžce pod doporučeným maximálním workloadem 180 TB za rok. SMART atributy nehlásí žádný problém, pouze ve statistikách (v GSmartControl) je Number of Reported Uncorrectable Errors: 2. Disk jsem projížděl v průběhu času několikrát Extended SelfTestem, poslední jsem dělal při nalítaných 29,5k hodinách a vše OK.
Nakonec na něm není NTFS, ale exFAT systém, protože je méně agresivní na náhodné zápisy (lépe bych měl říct „nikoli sekvenční zápisy“). Slouží jako běžné diskové úložiště převážně větších souborů, ale také některých malých, je na něm např. můj Thunderbird profil čítající 5,37 GB v téměř 4 tisících souborech a 563 složkách. Obsazenost disku ve WinDirStatu vypadá takto:
https://abload.de/img/seagatearchove8tb-winz7j1m.png
Samozřejmě se poohlížím po větším úložišti. Od té doby, kdy jsem tuhle recenzi dělal, mě překvapilo, že SMR disky spíš upadly v zapomnění a víc se jde do héliových. Přitom ta technologie na doma aspoň podle toho, co mohu říct z vlastní zkušenosti, vůbec není blbá. Na to, že to je jen kompromis, je to docela použitelné, plus k tomu ta nižší cena.
Taky mě překvpailo, že ceny disků od té doby nijak významně nespadly. Ony ale ani nijak výzmnamně nenarostly kapacity. Je vidět, že výrobci disků jsou už de facto na fyzikálních limitech, jiné technologie jdou stále kupředu, ale u disků už moc není jít kam, jako by se to ždímalo do posledního bitu.Je možné, že nás ještě čeká nějaké technologické překvapení (např. slibovaný HAMR/TAMR apodMR) je pořád ještě spíš Sci-Fi (byť magnetooptika, ze které toto řešení vychází, je naopak doménou muzeí).
Díky za update WIFTe. Mně už taky 2TB RAID1 pole z disků dost brutálně nestačí, ale tak nějak právě nevím, do čeho jít.
Teď jsem koukal, že diskům je už přes 7 let a tehdy jeden kus (WD green s tím vypnutým neustálým parkováním hlav :)) stál 2300 Kč. Dneska bych si za to koupil 3TB disk .... to se tedy moc nepohlo.
Poslední dobou jsem to uvažoval vyřešit tak, že RAID1 rozpadnu a budu se spoléhat na zálohu na počítačích a externím disku (to je nějaký 4TB 2,5 usb disk; takže asi taky šindel, ale to mi na rsync nějak nevadilo). Zatím vítězí lenost a neřeším to :D
Ono na křečkování videí nemám už čas ani sílu a předplacené streamingové služby za pár stovek měsíčně to docela hezky řeší.
Požívám tyto HDD dva, cca i stejnou dobu jako je datum této recenze a bez sebemenšího problému. Čistě jako úložiště pro objemné soubory které vesměs jenom čtu. Např. tam je filmotéka v PLEXu.
Ze začátku sem měl také lehkou nedůvěru k této technologii, ale ukázalo se že nebyla opodstatněná. ( rychle zaklepat na dřevo :-) )
Díky za info!
Já ho nakonec před těmi 3 roky taky koupil. Nalítáno mám tedy jenom 5k v hodinách, ale jsem spokojen. Funguje jako odkladiště větších věcí a moc tam nechodím, ale zapnutý bývá, protože se nachází v pracovní mašině. Zatím taky bez chyb, tak snad nám to tak vydrží i nadále...
Tohle je jeden z mála článků, ke kterým se čas od času vrátím.
Wifte, tohle byl společně s tím endurance testem SSD masterpiece. Věřím, že jste napsal spoustu článků, které považujete za lepší, ale tohle jsou pro mě legendy, a moc takových na českém webu není.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.