Suosittele kiintolevyä

  • Keskustelun aloittaja Keskustelun aloittaja Make
  • Aloitettu Aloitettu
Datan lukemisessa ei ole mitään ongelmaa, mutta jos kirjoittaa kerralla paljon niin hidastuu aika rajusti:

Tuossa on mielestäni nyt epäkohta. Tiedostosilppu on vielä paljon pahempi kuin isot tiedostot (tai kirjoitukset jotka menevät suhteellisen peräkkäiselle levyalueelle). Varsinkin silloin kun levy rupeaa täyttymään, niin tuo voi hidastaa kirjoituksia "lähes rajattomasti", hyvin voi päästä alle 1MB/s tasoon. Tuohan on se tilanne, missä jo ei SMR levytkin hidastuu erittäin merkittävästi ja myös SSD levyt (4k random write). Puhumattakaan sitten SMR:stä. Isojen tiedostojen kopiointi SMR:lle, silloin kun on yhtenäistä levytilaa tarjolla, ei ole ollenkaan paha juttu.

Koti-mediapalvelimesta kuulen kun sen levy täyttyy vaikka se on tuolla kaapissa. Siirrot palvelimelle hidastuu ja alkaa kuulumaan kauhea rouskutus, kun ne viimeisetkin vapaat clusterit pitää etsiä sieltä missä ne sitten sattuukin olemaan hajallaan pitkin levyä.
 
Tuossa on mielestäni nyt epäkohta. Tiedostosilppu on vielä paljon pahempi kuin isot tiedostot (tai kirjoitukset jotka menevät suhteellisen peräkkäiselle levyalueelle). Varsinkin silloin kun levy rupeaa täyttymään, niin tuo voi hidastaa kirjoituksia "lähes rajattomasti", hyvin voi päästä alle 1MB/s tasoon. Tuohan on se tilanne, missä jo ei SMR levytkin hidastuu erittäin merkittävästi ja myös SSD levyt (4k random write). Puhumattakaan sitten SMR:stä. Isojen tiedostojen kopiointi SMR:lle, silloin kun on yhtenäistä levytilaa tarjolla, ei ole ollenkaan paha juttu.

Koti-mediapalvelimesta kuulen kun sen levy täyttyy vaikka se on tuolla kaapissa. Siirrot palvelimelle hidastuu ja alkaa kuulumaan kauhea rouskutus, kun ne viimeisetkin vapaat clusterit pitää etsiä sieltä missä ne sitten sattuukin olemaan hajallaan pitkin levyä.

Tuo tiedostosilppu mitä tarkoitin on 25-50MB kuvia jotka siirsin levyjen käyttöönotossa levyille ja ne upposi ihan nätisti hidastumatta kohtuuttomasti (ainakin verkon ylitse). Samalla tavalla vähän isommat tiedostot (500MB-1GB) tähän tyyliin: (tiedostojen yhteiskoko vajaat 60GB). Tuo ensimmäinen kuvakaappaus on tiedostoista jotka ovat 4GB per tiedosto.
 
Tuo tiedostosilppu

Aivan, siis tässähän pitää muistaa se olennainen pointti että SMR hidastuminen tulee esille vasta tietyn määrän jälkeen. Sama lienee monissa muissakin SSD levyissä. Olen pitkään ihmetellyt miten 4K random write voi olla niin korkea, mutta testit tehdään väärin. Sitä neljän kilon silppua pitäisi työntää sinne levylle monta gigaa. Jos testi tehdään vain "muutaman gigan" silppu määrällä, ongelma ei ehdi ilmenemään. - Sippu menee ihan hyvin SMR:n ja SSD:n kirjoituspuskuriin, jos sitä on tarpeeksi vähän. Siihen vaikuttaa myös levyn fragmentoitumistilanne, tiedostojärjestelmä jne kaikki perusjutut. Eikä ne isotkaan tiedostot sinne nätisti tipu jos vapaa tila on fragmentoitunut. Mutta toivottavasti noita levyjä ei kukaan moisessa käytössä käytä, koska se olisi ihan totaalista tuhoa suorituskyvyn kannalta.
 
Mitäs lättyä kannattaa nykyisin hommata jos on askartelemassa raid-pakkaa? Tarkoituksena olisi aloittaa kolmella levyllä ja laajentaa siitä eteenpäin jos/kun tarvitsee tilaa ja nopeutta. Nykyisin on vastaava ratkaisu neljällä 1tb:n lätyllä, mutta kapasiteeti loppuu kesken. Ajattelin kokoluokkaa 3-6tb/levy, ihan riippuen siitä missä saa eniten rahalle vastinetta.
 
:hmm: Laajenna nykyistä pakkaa lisäämällä levyjä. Tilavuus ja nopeus kasvavat. Homma Sata 6 Gb/s sovitinkortti (n 15 €) johon saat 4-8 levyä lisää ....
 
Ajattelin vaihtaa isompiin lättyihin tulevaisuudenkin skaalautuvuutta ajatellen. Rupeaa kotelo olemaan suhteellisen täynnä ja tera kerrallaan laajentaminen tuntuu aika puuhastelulta
 
Homma Sata 6 Gb/s sovitinkortti (n 15 €) johon saat 4-8 levyä lisää ....
Itse hommasin alista tollaisen sovitinkortin, eikä se toiminut kunnolla niillä mukana tulleilla ajureilla, vaan sata liitäntä oli epävakaa. Ostin isommat kiintolevyt teran ja 500 gb tilalle, ja toimii paljon paremmin. Kokeilen ehkä myöhemmin uudelleen toimivuutta, mutta nyt on vain pölyyntymässä.
 
Vastataan nyt omiin huhuiluihin. Tämmöiset Hitachin 3Tb 7200rpm lätyt tuli hommattua hintaseurannan paukuttelun jälkeen. Ebaysta olisi saanut jotain käytettyjä seagateja halvemmalla, mutta otti järki vastaan siinä vaiheessa hintavertailua. Vaikutti aika lyömättömälle diilille, lopulliseksi pakan koksi 4*3 teraa.
 
Mitäs lättyä kannattaa nykyisin hommata jos on askartelemassa raid-pakkaa? Tarkoituksena olisi aloittaa kolmella levyllä ja laajentaa siitä eteenpäin jos/kun tarvitsee tilaa ja nopeutta. Nykyisin on vastaava ratkaisu neljällä 1tb:n lätyllä, mutta kapasiteeti loppuu kesken. Ajattelin kokoluokkaa 3-6tb/levy, ihan riippuen siitä missä saa eniten rahalle vastinetta.
Raid pakkaa millä tekniikalla? ZFS tuntuu olevan kovin suosittu. Jos taas käytät jotain jotain perinteisiä raideja, niin silloin pitää muistaa että levyjen määrä vaikuttaa myös pakan luotettavuuteen. Kaksi levyä mirrorituna, RAID5 / RAID6 jne. 3 teran levyt taitanee olla joo halvimpia giga hinnaltaan tällä hetkellä. Valittu tapa, levyjen määrä ja siirtonopeus vaikuttaa toki myös pakan suorituskykyyn jne. Sekä erityisesti SMR levyillä ZFS pakan rebuildi voi olla itsemurha, se kun ei tapahdu lineaarisesti.

Tuossa justiin huvikseni laskeskelin, että SMR levyllä kirjoitusnopeus voi laskea alle 100 KB/s tasoon worst case skenarioissa (4 kibytes clustereilla). En ole moista testiä tehnyt levylle, mutta oikeastaan voisi tehdä, ihan proof of conceptina. Katsoa mikä on käytännön tulos testistä. Joku päivä kun on sopiva motivaatio päällä niin voisin tehdä tuon, eihän tuohon kauaa mene. Siis testisoftan kirjoittamiseen, itse testin ajamiseen voi kyllä mennä pitkä tovi ja sitten vielä se kauhein asia. Kun levyn on saanut tuolla testillä ajettua täysin tukkoon, niin kauanko kestää että se kirjoituspuskuri tyhjenee. Mun laskelmien mukaan se voi kestää useita päiviä. Joten mietin vielä, että haluanko tehdä tuota testiä sellaisella levyllä joka ei ole jatkuvasti virroissa ja sillä ole aikaa viikkoa tuosta toipua.
 
Viimeksi muokattu:
Tyhmä kysymys: onko SMR siis ongelma lähinnä silloin kun levylle kirjoitetaan paljon tavaraa hyvin usein? Itse kun käytän NASia käytännössä mediavarastona niin aivan jatkuvaa kirjoitustarvetta ei ole vaan yleensä siirrän aineistoa kerran parissa viikossa ehkä 20-30 gigaa kerrallaan. Sen lisäksi tehdään välillä metatietojen skannauksia ja päivityksiä, mutta ne koskevat kirjoitusmielessä vain pieniin nfo-tiedostoihin.
 
Tyhmä kysymys: onko SMR siis ongelma lähinnä silloin kun levylle kirjoitetaan paljon tavaraa hyvin usein? Itse kun käytän NASia käytännössä mediavarastona niin aivan jatkuvaa kirjoitustarvetta ei ole vaan yleensä siirrän aineistoa kerran parissa viikossa ehkä 20-30 gigaa kerrallaan. Sen lisäksi tehdään välillä metatietojen skannauksia ja päivityksiä, mutta ne koskevat kirjoitusmielessä vain pieniin nfo-tiedostoihin.

En mä tätä hitautta näkis ongelmana, mutta nas käyttöön näitä ei ihan hirveästi suositella:

This means more data can be stored on a shingled disk than an ordinary drive. However, SMR drives are not intended for random write IO use cases because the write performance is much slower than with a non-SMR drive. Therefore they are not recommended for NAS use cases featuring significant random write workloads.

Itsellänikin on pääasiassa media/backup levyinä kolme SMR limppua ja omaan käyttöön täysin riittävä ratkaisu.
 
Jäin vielä miettimään että jos ajaisin noi SMR testit ihan viihteen vuoksi. Onko ketään jota kiinnostaa tulokset? Voisin ajaa ulkoisella Toshiban 3 TB canviolla noi testit.

Testi suunnitelma:
1) Kirjoita levy täyteen randomia
2) Vaihda kirjoitus patterni randomiksi 4 kilon lohkoksi (direct disk I/O) ja lisää satunnaisessa järjestyksessä satunnaista dataa levylle
3) Logita kirjoitusnopeus, iopsit, jne koko testauksen ajan minuutin välein

Odotettu tulos:
1) Menee perusvauhtia, eli tuolla levyllä noin 113 megatavua sekunnissa (levyn alku, siitä tasaisesti laskien).
2) Menee muutaman kymmentä gigaa hyvää vauhtia, ja sen jälkeen vauti hyytyy kuin seinään (~50 - 100 kibytes/s), I/O latenssi per IOPS räjähtää järjettömäksi ja IOPS lukemat on arviolta luokkaa ~10 - 15 IOPS.
3) Kun testi lopetetaan, levy jatkaa yli kaksi vuorokautta tuon kirjoituspuskurin tyhjentämistä. Nopealla nenäliinamatikalla arvioituna menee jotain 2 - 4 vuorokauden välillä.

Viitsinkö ajaa testit, setuppiin menee ehkä vartti.
 
En mä tätä hitautta näkis ongelmana, mutta nas käyttöön näitä ei ihan hirveästi suositella:

This means more data can be stored on a shingled disk than an ordinary drive. However, SMR drives are not intended for random write IO use cases because the write performance is much slower than with a non-SMR drive. Therefore they are not recommended for NAS use cases featuring significant random write workloads.

Itsellänikin on pääasiassa media/backup levyinä kolme SMR limppua ja omaan käyttöön täysin riittävä ratkaisu.
Niin siis... se ongelma on yksin tuo SMR hitaus tietyillä kuormilla. Ihan sama onko levyt kiinni NASissa tai missä vaan. NAS+SMR ei ole mikään ongelmakombo.
 
Varmuuskopioille olis tarvis 2-3TB HDD. WD Blue varmaan ihan riittävä siihen?
 
Varmuuskopioille olis tarvis 2-3TB HDD. WD Blue varmaan ihan riittävä siihen?

On, mutta hinnassa ei liene valtava ero jos ostaa isomman? Monet tekee sitä, että ostavat usb-levyn ja ottaa sieltä kimpun talteen ja näin itsekin teen. Tosin tämä voi vaikuttaa takuuseen :p

Googleen: USB hdd shucking
 
On, mutta hinnassa ei liene valtava ero jos ostaa isomman? Monet tekee sitä, että ostavat usb-levyn ja ottaa sieltä kimpun talteen ja näin itsekin teen. Tosin tämä voi vaikuttaa takuuseen :p

Googleen: USB hdd shucking
Tuo 2-3TB riittää oikein hyvin. Ja ei ole noin euron päälle, että tuollaista jaksaisi säätää
 
Niin siis... se ongelma on yksin tuo SMR hitaus tietyillä kuormilla. Ihan sama onko levyt kiinni NASissa tai missä vaan. NAS+SMR ei ole mikään ongelmakombo.

Lopulliset faktat tulee huomenna, mutta todettakoon että 4k randomit oli SMR:llä about:
37 IOPS = 150kt/s ensimmäiset 90 minuuttia, joka oli yllättävän pitkään mielestäni. Olin jotenkin kuvitellut että tuo puskuriin kirjoitus menisi vielä paljon nopeammin.

Kun tuo kirjoituspuskuri täyttyi, nopeus putosi noin kahdeksasosaan, about sitä luokkaa mitä olinkin odotellut.
~5 IOPS = 20 kt/s.

Samalla levyn I/O latenssit pomppasi sellaiseen tasoon, että välillä kesti 10 sekuntia yksi IOPS, kun ei ollut enää tilaa mihin sitä laittaisi ja oli pakko odotella että DM-SMR hoitaa jostain tallennustilaa. Jos tuota joutuu joku käyttäjä odottelemaan, niin se kyllä menettää hermonsa.

Annoin tuon hitaan vauhdin rullutella 30 minuuttia. Pistin poikki ja nyt on selvitys menossa, kauanko toipuminen kestää. Viisi tuntia mennyt ja edelleen järjestelee datoja, katsotaan onko aamulla vielä sama tilanne.

Samalla on käynnissä testi, joka kerran minuutissa testaa levyn latenssia. Katson muuttuuko tilanne jotenkin kun tuo sisänen järjestely on valmis. Ehkä muuttuu, ehkä ei. Tuolla on merkitystä sen suhteen, että jos latenssi laskee merkittävästi järjestelyn loppumisen jälkeen, niin se tarkoittaa sitä, että levy on erittäin hidas, siihen asti kunnes tuo järjestely on päättynyt.

Tämä testi siis Toshiba Canvio 3 TB levyllä, mutta tää nyt oli ihan odotettava tulos, ja oletan että koskee yleisesti muitakin SMR levyjä.

Riippuen käytöstä SMR levy on joko täydellinen katastrofi, tai käyttäjä ei huomaa mitään eroa. Siksi tämä on hyvä väittelynaihe onko ne huonoja vai ei.
 
Viimeksi muokattu:
Tarkistin nyt logit, tl;dr; versio menee näin.

Kirjoituspuskurin täyttyminen kesti 90 minuuttia, sen jälkeen suorituskyky putosi noin 90%. Puskurin purkautuminen ja levyn palaaminen normaaliin kesti 9 tuntia.

Ilmeisesti tuossa levyssä on joku head park tms ominaisuus, koska puskurin purkauduttua itseasiassa I/O latenssi kasvoi merkittävästi, mutta todennäköisesti johtuen siitä, tein 20 IOPSia kerran minuutissa. Eli levy ehti todeta tuossa minuutissa, että sitä ei käytetä ja siksi heräsi hitaammin pyyntöihin kuin puskuria tyhjentäessään. Tämä oli vähän yllätys minulle, mutta selvästi indikoi ajan kauanko puskurin tyhjennys kesti. Oletin että tuossa olisi käynyt juuri toisin päin, ja vasteajat olisi laskenut kun puskuri tyhenee. Tämä olisikin todennäköisesti tilanne, jos olisin lukenut levyä useammin.

Tuo siis tuollaisena perustaustatietona, kun miettii onko SMR ongelma vai ei.
 
Tarkistin nyt logit, tl;dr; versio menee näin.

Kirjoituspuskurin täyttyminen kesti 90 minuuttia, sen jälkeen suorituskyky putosi noin 90%. Puskurin purkautuminen ja levyn palaaminen normaaliin kesti 9 tuntia.

Ilmeisesti tuossa levyssä on joku head park tms ominaisuus, koska puskurin purkauduttua itseasiassa I/O latenssi kasvoi merkittävästi, mutta todennäköisesti johtuen siitä, tein 20 IOPSia kerran minuutissa. Eli levy ehti todeta tuossa minuutissa, että sitä ei käytetä ja siksi heräsi hitaammin pyyntöihin kuin puskuria tyhjentäessään. Tämä oli vähän yllätys minulle, mutta selvästi indikoi ajan kauanko puskurin tyhjennys kesti. Oletin että tuossa olisi käynyt juuri toisin päin, ja vasteajat olisi laskenut kun puskuri tyhenee. Tämä olisikin todennäköisesti tilanne, jos olisin lukenut levyä useammin.

Tuo siis tuollaisena perustaustatietona, kun miettii onko SMR ongelma vai ei.
Mitä sä sinne levylle laitoit? Pystyisikö levyn laittaa automaattisti kirjoittamaan ilman että tarvitsee alkaa järjestelemään levyä, jos satoja gigoja kirjoitaa levylle kerralla pääasiassa isoja tiedostoja?
 
Mitä sä sinne levylle laitoit? Pystyisikö levyn laittaa automaattisti kirjoittamaan ilman että tarvitsee alkaa järjestelemään levyä, jos satoja gigoja kirjoitaa levylle kerralla pääasiassa isoja tiedostoja?

Mitä laitoin levylle? 4 kilon data lohkoja, pseudosatunnaisiin osoitteisiin (non 4k aligned!). Eli niin sanotusti aikalailla pahin mahdollinen yhtälö SMR:n osalta. Tavoitteena oli testata miten huono se SMR:n suorituskyky on, silloin kun se on huono. Ja olihan se aikalailla heikko, joskin ihan odotettavissa. Jos kerran shinglessä on 4 - 5 layeria, tarkoittaa se sitä, että shinglen uudelleenkirjoitus tarvitsee ~10 levyn ympäripyörähdystä. Tuon voi siis aika helposti laskea shinglet / pyörimisnopeus. Jotta tuo 4 kiloa voidaan shingleen kirjoittaa, pitää levyn pyörähtää 8 - 10 kertaa ympäri. Esin pinkka luetaan ja sitten kirjoitetaan muokattuna takaisin.

Todellakin tilanne on aivan toisenlainen, jos koko tuo pinkka kirjoitetaan kerralla yli, silloin sitä ei tarvitse lukea. Tämä on se syy, miksi ongelma ei ole isolla yhtenäisillä kirjoituksilla niin paha, koska tuolta suorituskyvyn vähintään puolittavalta, lukemisvaiheelta voidaan pääsääntöisesti säästyä.

Sitä en tiedä osaako jotkut asemat optimoida tuon niin, että ne kirjoittaa vain osan shingleistä uudelleen, eli jos pakka on "5 layeria syvä", niin voik siihen kirjoittaa vain kaksi viimeisintä päälle, kuulostaa ihan todennäköisesti mahdolliselta ja fiksulta optimoinnilta.

Oma kokemus isoista kirjoituksista on käytännössä se, että tuo SMR hidastuminen heiluu jossain 50-0% välillä. Pääsääntöisesti ehkä kuitenkin vain ~10% hidastumista verrattuna non-SMR levyyn. Eli ei ollenkaan niin hirveää kun se voisi olla. Tämä siis kun levylle kirjoitetaan 4 gigan fileitä putkeen, lukematta käytännössä mitään välissä.
 
Mitä laitoin levylle? 4 kilon data lohkoja, pseudosatunnaisiin osoitteisiin (non 4k aligned!). Eli niin sanotusti aikalailla pahin mahdollinen yhtälö SMR:n osalta. Tavoitteena oli testata miten huono se SMR:n suorituskyky on, silloin kun se on huono. Ja olihan se aikalailla heikko, joskin ihan odotettavissa. Jos kerran shinglessä on 4 - 5 layeria, tarkoittaa se sitä, että shinglen uudelleenkirjoitus tarvitsee ~10 levyn ympäripyörähdystä. Tuon voi siis aika helposti laskea shinglet / pyörimisnopeus. Jotta tuo 4 kiloa voidaan shingleen kirjoittaa, pitää levyn pyörähtää 8 - 10 kertaa ympäri. Esin pinkka luetaan ja sitten kirjoitetaan muokattuna takaisin.

Todellakin tilanne on aivan toisenlainen, jos koko tuo pinkka kirjoitetaan kerralla yli, silloin sitä ei tarvitse lukea. Tämä on se syy, miksi ongelma ei ole isolla yhtenäisillä kirjoituksilla niin paha, koska tuolta suorituskyvyn vähintään puolittavalta, lukemisvaiheelta voidaan pääsääntöisesti säästyä.

Sitä en tiedä osaako jotkut asemat optimoida tuon niin, että ne kirjoittaa vain osan shingleistä uudelleen, eli jos pakka on "5 layeria syvä", niin voik siihen kirjoittaa vain kaksi viimeisintä päälle, kuulostaa ihan todennäköisesti mahdolliselta ja fiksulta optimoinnilta.

Oma kokemus isoista kirjoituksista on käytännössä se, että tuo SMR hidastuminen heiluu jossain 50-0% välillä. Pääsääntöisesti ehkä kuitenkin vain ~10% hidastumista verrattuna non-SMR levyyn. Eli ei ollenkaan niin hirveää kun se voisi olla. Tämä siis kun levylle kirjoitetaan 4 gigan fileitä putkeen, lukematta käytännössä mitään välissä.
Eli pitäisi toimia ihan hyvin medialevynä, jonne vain tallennetaan ja luetaan vlc playerilla.
 
Eli pitäisi toimia ihan hyvin medialevynä, jonne vain tallennetaan ja luetaan vlc playerilla.

Kuten todettu joo, toimii mainiosti sellaisessa käytössä missä ei tarvita jatkuvaa hajakirjoitusta. Backupeissa toimii myös mainiosti.

Hajakirjoitus käytössä kannattaa luonnollisesti suunnata SSD puolelle.
 
Onko muutes joku muu syy kuin hinta että miksei porukka täälä käytä Ironwolfeja?
 
Sopivatko Seagaten Ironwolf tai Exos levyt kotikäyttöön eli ei palvelin/NAS tai valvontakameroihin vaan normaalin koneen sisälle tai ulkoiseen telakkaan silloin tällöin käytettäväksi? Etsin suurikapasiteetillisia levyjä kotivarmuuskopiointiin koska 4K videot sun muut vievät tilaa. Nämä olisi halvimmat mallit yli 12 TB kokoluokassa. Muut "normaaliin" käyttöön tehdyt maksaa yli tuplasti enemmän ja näissä taitaa olla 5-vuoden takuu. Kirjoitustarvetta tulee ehkä kerran viikossa mutta levyn lukua tulee useammin.
 
Viimeksi muokattu:
Sopivatko Seagaten Ironwolf tai Exos levyt kotikäyttöön eli ei palvelin/NAS tai valvontakameroihin vaan normaalin koneen sisälle tai ulkoiseen telakkaan silloin tällöin käytettäväksi? Etsin suurikapasiteetillisia levyjä kotivarmuuskopiointiin koska 4K videot sun muut vievät tilaa. Nämä olisi halvimmat mallit yli 12 TB kokoluokassa. Muut "normaaliin" käyttöön tehdyt maksaa yli tuplasti enemmän ja näissä taitaa olla 5-vuoden takuu. Kirjoitustarvetta tulee ehkä kerran viikossa mutta levyn lukua tulee useammin.
Toki sopivat. Itselläni on useita palvelinsalikäyttöön tehtyjä kiintolevyjä. Ne on työasemassani pikairrotettavissa kiintolevykehikoissa. Hyvin toimivat siinä.
 
Sopivatko Seagaten Ironwolf tai Exos levyt kotikäyttöön eli ei palvelin/NAS tai valvontakameroihin vaan normaalin koneen sisälle tai ulkoiseen telakkaan silloin tällöin käytettäväksi? Etsin suurikapasiteetillisia levyjä kotivarmuuskopiointiin koska 4K videot sun muut vievät tilaa. Nämä olisi halvimmat mallit yli 12 TB kokoluokassa. Muut "normaaliin" käyttöön tehdyt maksaa yli tuplasti enemmän ja näissä taitaa olla 5-vuoden takuu. Kirjoitustarvetta tulee ehkä kerran viikossa mutta levyn lukua tulee useammin.
Kyllä, itselläki Ironwolfi koneessa normaali käytössä, itse ainaki olen siinä ymmärryksessä että nämä kestäis normaali levyjä paremmin. Tuskinpa sitä viiden vuoden takuuta ja datanpalautusta voidaan luvata kylkeen semmoseen levyyn mikä on yötäpäivää tarkotettu ajettavaksi jos ihan paska olis.
 
Ei oikein yli 12tb herätä luottoa jos tämmösiä kuvia kattelee :D
 

Liitteet

  • levykevy.jpg
    levykevy.jpg
    291,4 KB · Luettu: 226
Ei oikein yli 12tb herätä luottoa jos tämmösiä kuvia kattelee :D
18tb lättyjä on 60 kpl jotka ovat paskoja, luultavasti samalla erää tilattu ja joku valmistevika. Mitä muu ei herätä luottoa tuossa?
Edit; katsoin väärä riviä, 60 kpl joista 2 hajalla, ei kerro mitään.
 
Viimeksi muokattu:
18tb lättyjä on 60 kpl jotka ovat paskoja, luultavasti samalla erää tilattu ja joku valmistevika. Mitä muu ei herätä luottoa tuossa?
Edit; katsoin väärä riviä, 60 kpl joista 2 hajalla, ei kerro mitään.
Joo, en tuosta yhdestä luvusta vetäisi vielä johtopäätöksiä. Käytännössä joka vuosi, Seagate "johtaa" Backblazen failure tilastoja ja yli 1% annualized failure ratea voidaan pitää huonohkona, ja usein % on lähempänä kahta, kuin yhtä.

Toki merkittävyys kotikäyttäjälle on pieni, jos joka 50. lätty hajoaa vuosittain, mutta tietty mielikuva tuosta välittyy. Etenkin Seagaten Barracuda (kuluttajalevy) 3tb versio jätti muistijäljen, Backblazen tilastoissa yhtenä vuonna pikaisella Googlauksella failure rate oli yli 40 %. Vuosia olen tilastoja seurannut ja aina Seagate johtaa tilastoja. Yhdistettynä Barracuda-failureen, luottamus on mennyt.

Backblazen tilastoissa on usein myös vanhempaa rautaa, koska tässä haetaan pitkäikäisyyttä - joka selviää vasta pitkän ajan päästä. ;)

Tässä vielä 2019 tilasto. Backblaze jakaa sivuillaan vielä raakaa testidataa, jos kiinnostaa enemmän.

1612855803518.png
 
Mulla olisi yksi levy kiinni koneessa ja toinen telakassa varmuuskopiontiin. Uskon että kahden levyn yhtäaikainen hajoaminen on tässä tapauksessa aika harvinaista kun vain yksi on viikoittain 7h päivä virroissa. Jos haluaisi vielä leikkiä hankkisi kolmannen levyn eri valmistajalta ja kaikkiin samat tiedot.
 
Joo, en tuosta yhdestä luvusta vetäisi vielä johtopäätöksiä. Käytännössä joka vuosi, Seagate "johtaa" Backblazen failure tilastoja ja yli 1% annualized failure ratea voidaan pitää huonohkona, ja usein % on lähempänä kahta, kuin yhtä.

Toki merkittävyys kotikäyttäjälle on pieni, jos joka 50. lätty hajoaa vuosittain, mutta tietty mielikuva tuosta välittyy. Etenkin Seagaten Barracuda (kuluttajalevy) 3tb versio jätti muistijäljen, Backblazen tilastoissa yhtenä vuonna pikaisella Googlauksella failure rate oli yli 40 %. Vuosia olen tilastoja seurannut ja aina Seagate johtaa tilastoja. Yhdistettynä Barracuda-failureen, luottamus on mennyt.

Backblazen tilastoissa on usein myös vanhempaa rautaa, koska tässä haetaan pitkäikäisyyttä - joka selviää vasta pitkän ajan päästä. ;)

Tässä vielä 2019 tilasto. Backblaze jakaa sivuillaan vielä raakaa testidataa, jos kiinnostaa enemmän.

1612855803518.png
Miksi WD merkkisiä levyjä ei ole ollenkaan?
 
Miksi WD merkkisiä levyjä ei ole ollenkaan?
Hinta. Niitä on ollut aiemmin ("but over the years we’ve never been able to get the quantity of Western Digital drives we need at a reasonable price", lähde). En tiedä, onko koko totuus. HGST on kuitenkin hyvin edustettuna, joka on WD:n omistuksessa.
 
Onko tässä viimeisen puolen vuoden aikana kukaan puukottanu 8terasia Wd My Bookkeja? Itse noin tasan vuosi sitten tilasin kaksi kappaletta ja molemmat oli wd80ezaz -malleja. Kiinnostaa onko mukana tuleva levy muuttunut.
 
Olisiko suosituksia ulkoisesta kovalevystä television tallennuksia varten? Vanhemmat haluaa tehdä asiat vielä tällä tavalla...
 
Olisiko suosituksia ulkoisesta kovalevystä television tallennuksia varten? Vanhemmat haluaa tehdä asiat vielä tällä tavalla...
Tuo on parillakin eri tv:llä toiminut, ja hyvässä tarjouksessakin. Ei ole omaa softaa tms, niin kaikista toimintavarmin, oli se sitten TV, pleikkari tai muu vastaava. Ja onhan Gigantilla myös 50pv palautusoikeus, jos ei pelitäkään.
 
Tuo on parillakin eri tv:llä toiminut, ja hyvässä tarjouksessakin. Ei ole omaa softaa tms, niin kaikista toimintavarmin, oli se sitten TV, pleikkari tai muu vastaava. Ja onhan Gigantilla myös 50pv palautusoikeus, jos ei pelitäkään.

Kiitokset, täytyypi laittaa tuollainen tilaukseen
 
Mikähän näiden kahden levyn suurin ero mahtaa olla?

Western Digital Elements
WD My Book
Ei käytännössä mitään eroa.
Nopealla googletuksella:
MY BOOK
Uses WD Backup software to automatically backup selected file types when added or changed. Prices are a bit higher; for the software. Largest size it 8TB (TeraBytes). This would be good for users without much computer experience. There is a Password feature which provides some security, but if the Password is forgotten, there is no way to recover the files.

ELEMENTS
Uses standard Windows Copy or Move software for user to select files and where to save them. Prices are lower. Largest size is 4TB. Windows software requires some computer experience.

Tämä wd: sivulta, kirjoitettu 2018.
 
Kiitti. Jotain pieniä eroja näköjään on
Elements levyssä led-indikaattori, power nappi erikseen ja kahden vuoden takuu
My Book levyssä näköjään kolmen vuoden takuu ja jokin salaus softa
 
Olen purkanut pari tuollaista WD Elements 12Tb levyä (WD120EMFZ) koteloistaan ja laittanut serveriin. Levyt toimii ihan ok, mutta jotenkin tuntuu, että nuo ei noudata kiintolevyn sleep asetuksia mitä olen laittanut windows server 2019 virranhallinta asetuksista. Siellä on määritetty, että levyt menee nukkumaan 15 min idlen jälkeen. Nyt vaikuttaisi, että nuo nukahtaa ihan parissa minuutissa. Voiko tuota vielä yrittää säätää tai edes tarkistaa jotenkin miten nuo toimii? Vai onko tuolla edes väliä levyjen kestävyyden suhteen?
 
Olen purkanut pari tuollaista WD Elements 12Tb levyä (WD120EMFZ) koteloistaan ja laittanut serveriin. Levyt toimii ihan ok, mutta jotenkin tuntuu, että nuo ei noudata kiintolevyn sleep asetuksia mitä olen laittanut windows server 2019 virranhallinta asetuksista. Siellä on määritetty, että levyt menee nukkumaan 15 min idlen jälkeen. Nyt vaikuttaisi, että nuo nukahtaa ihan parissa minuutissa. Voiko tuota vielä yrittää säätää tai edes tarkistaa jotenkin miten nuo toimii? Vai onko tuolla edes väliä levyjen kestävyyden suhteen?

Ei hyvä jos nukkuvat liian nopeasti, silloin käynnistyksiä ja myös odotusta tulee turhaan.

Arvaan että levyillä on joku vitransäästöasetus joka sammuttaa ne. Esimerkiksi hdparm pitäisi osata näyttää asetukset levyltä. Toinen oli muistaakseni wdidle.
Levystä riippuen asetus tallentuu levylle tai jos haluaa muuttaa niin pitää muuttaa aina bootissa.
 
Tälläistä näyttää hdparm. Ymmärsinkö oikein, että tuo ei saanut luettua power asetuksia?

Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 0
Advanced power management level: unknown setting (0x00fa)
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
 
Viimeksi muokattu:
Tälläistä näyttää hdparm. Ymmärsinkö oikein, että tuo ei saanut luettua power asetuksia?

Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 0
Advanced power management level: unknown setting (0x00fa)
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns

Saihan se: "Advanced power management level: unknown setting (0x00fa)".

Yleensä suunnilleen näin:
Maximum performance FEh
Intermediate power management levels without Standby 81h-FDh
Minimum power consumption without Standby 80h
Intermediate power management levels with Standby 02h-7Fh
Minimum power consumption with Standby 01h
Reserved FFh
Reserved 00h

Valmistaja voi tietysti käyttää tuota arvoa miten sattuu. Periaatteessa APM- arvoa pitäisi voida rauhassa muuttaa ja katsoa miten levy reagoi kunhan ei käytä 0 tai 255.
Tähän mennessä kaikki levyt ovat jääneet pyörimään ilman virranssätöjä arvolla 254 (0xfe).
Minulla ei myöskään ole tullut vielä vastaan levyä joka muistaisi asetuksen jos käyttää virrattomana.

Kannattaa katsoa myös smart- tiedoista 193 Load_Cycle_Count, jos se on kovin korkea/kasvaa nopeasti niin sitten serverikäytössä kokeilisin jos ominaisuuden saisi pois. Hdparmin versiosta riippuen asetuksen saa -J parametrilla tai wdidle3.

Omassa serverissä levyt pyörii koko ajan (2kpl n. 68kh ja 2kpl n. 20kh)
 

Statistiikka

Viestiketjuista
263 000
Viestejä
4 563 367
Jäsenet
75 073
Uusin jäsen
parkkhe2

Hinta.fi

Back
Ylös Bottom