Windows Storage Spaces (raid-implementaatio)

[jultsu]

Käyttääkö kukaan muu tuota Windowsin "uutta" softaraidia? Tuli ensimmäisen kerran ilmeisesti Win8.1 mukana, löytyy vakiona myös Win10 käyttiksestä.

Olen tässä muutamat viime päivät testaillut eri konfiguraatioilla tuota, käytössä sekalainen nippu 3TB kuluttajaluokan 7200rpm levyjä, pääosin Toshibaa ja Seagatea, kytkettynä suoraan x79 emolevyyn SATA2-portteihin / Dell H200 raid-ohjaimeen (HBA) pci-e x8 väylässä.

Oli käytössä sitten 3 levyn simppeli raid5, 6 levyn raid6 tai 10 levyn raid6, kirjoitusnopeudet olivat aina yhtä surkeita, tippuen noin 20-30MB/s paikkeille hetken kuluttua kunhan jokin välimuisti saatiin ensin täytettyä suoralla 500MB/s lukunopeudella lähdelevyltä (1TB SATA3 SSD.) Tästä on ulkomaisilla foorumeilla lukuisia eri mainintoja, kaikilla tuntuvat kirjoitusnopeudet sakkaavan todella pahasti. Ehkä kattavin arvostelu jonka löysin on kolmeosainen:

Storage Spaces Performance Analysis - Part 1
Storage Spaces Performance Analysis - Part 2
Storage Spaces Performance Analysis - Part 3

Kirjoitusnopeudet ovat samalla koneella / levykokoonpanolla ja raid6-tasolla olleet noin kymmenkertaiset käyttäessäni Linuxia ja mdraidia, joten laitteistossa itsessään ei ole mitään vikaa, MS:n implementaatiossa vain on "pieniä" puutteita.

Sitten päätin kokeilla SSD-levyjä välimuistina (journaling) nopeuttamaan pariteettilaskentaa / kirjoittamista, ja foorumipuheiden mukaan kahden pariteettilevyn raidpakka vaatisi vähintään kolme ssd:tä "journaling" moodiin jotta tuota kuormitusta pystyisi siirtämään niille. Yhdellä pariteettilevyllä riittäisi kuulemma kaksikin levyä.

Nurkissa pyöri pari Samsungin 840 Pro SSD:tä, 256GB kapasiteetilla, joten iskin molemmat kiinni koneeseen sata3-väylään ja nakkasin niille journaloinnin päälle. Yllätyin positiivisesti kun tuolta 1TB SSD SATA3 levyltä kopioimani 250GB kokoinen yksittäinen tiedosto (virtualbox levyimage, täynnä dataa, ei nollatäyttöä) kopioituikin nyt noin 450-500MB/s jatkuvalla nopeudella tuolle luomalleni 9x3TB raid-osiolle (NTFS formatoitu), eli saatiin 20-kertainen parannus kirjoitusnopeuksiin ja käytännössä mentiin jatkuvasti lähdelevyn lukunopeuden rajoittamana Pienintäkään notkahdusta nopeudessa ei windowsin kopiointi-ikkunassa näkynyt, ja tehtävienhallinnasta tuota raid-osiota katsoessa se raportoi kirjoitusnopeuden myös sahaava melko säännöllisesti 400-600MB/s, notkahtaen välillä nolliin. Noista kahdesta SSD-levystäkin vain toista käytettiin jatkuvasti ja toinen idlaili täysin, joka myös aiheuttaa ihmetystä kun foorumipuheet kertoivat että nuo SSD:t menisivät raid1-tilaan datan eheyden varmistamiseksi joten oletin että molempia myös kuormitettaisiin tasaisesti..

Ajelin varmuuden vuoksi SHA256 testit myös lähde / kohdeasemilla ja identtinen tiedostohan sinne kopioitui, niinkuin pitikin.

Testasin myös vain yhden ssd-levyn käyttöä journalointiin, ja nopeudet romahtivat taas 20-30MB/s tasolle, joten tuo SS selkeästi vaatii kaksi levyä, vaikka ei käyttäisi kuin vain toista.


Seuraavien päivien aikana tarkoitus testata vielä ReFS tiedostojärjestelmää NTFS:n tilalla, leikkiä ehkä "interleave" asetuksilla (käsittääkseni vastaa stripe sizeä?) ja katsoa kuinka hyvin tuo tokenee yhden / kahden levyn menetyksestä (mukaanlukien journalointiSSDt) sekä automaattisesta rebuildista / sen nopeudesta. Sähkökatkojen / BSODien simulointiakin voisi harrastaa ja katsoa miten tuo ReFS / journalointilevyt selviää siitä.

 

[jultsu]

No, yhteen kysymykseen voin jo vastata. Toisen, tai molempien journalointi-SSD -levyjen irroitus (softalla tai fyysisesti) ei vaikuttanut kirjoitusnopeuksiin kuin hetkellisesti, 250GB tiedosto puksutti menemään iloisesti loppuun asti 480MB/s vaikka molemmat SSD:t olivat irti jo puolenvälin kohdalla
Softalla vaihdoin ensin SSD:t pois journaloinnista ja takaisin "AutoSelect" tilaan, ja kun toisen SSD:n käyttö välimuistina ei loppunut, kokeilin "retired" tilaa, ja kun SSD:n käyttö pysyi vieläkin samana, rykäisin virtajohdon irti molemmista.
Keskusmuistia tuo ei myöskään käytä väliaikavarastona tuossa SSD-levyjen tilalla, eikä myöskään lähdelevyä, ja muita ssd-levyjä ei koneessa ole tällä hetkellä kiinni.

Niin, tuli toki ajettua hash-testi tuolle tiedostolle jälleen, ja se kopioitui viimeistä bittiä myöten oikein..

Onhan tämäkin toki tapa myydä SSD-levyjä kylkiäisiksi isompiin raid-projekteihin.


edit. tuo nopeus säilyy edelleen, lukuisten reboottien jälkeenkin. Tasaista 500MB/s kirjoitusta, ilman SSD-levyjä, 9x3TB raid6 pakalla, jolla ennen jäätiin 25MB/s kirjoitusnopeuksiin.

 

[jultsu]

Okei, pientä blogintynkää pitänee heti viritellä.

SSD-levyjen käyttö journaloinnissa on parhaimmillaankin bugista. Ei riitä että levyt iskee "journaling" moodiin, vaan ne pitää fyysisesti lisätä myös pooliin mukaan. Lisäksi jos levyt lisää olemassaolevaan pooliin, ei niitä käytetä vaikka mitä tekisi. Pooli pitää tuhota kokonaan ja luoda uusi, tämän jälkeen SS nappaa nuo SSD:t mukaan cachettaamaan. Crystaldiskmarkin testien perusteella nopeutus on noin 50% lisää. SSD-levyjen iskeminen kesken kaiken "retired" moodiin ei kuitenkaan poista niitä cachettamasta. Huoh.

 

[mRkukov]

Omat kokemukset winkkarin raideista:
Raid 1 ja raid 0 ok. Älä edes yritä muita.

 

[jultsu]

Joo, ei tämä vielä aivan täysin valmis tuote vaikuta olevan. Taustalla tuntuu tapahtuvan kaikenlaista, johon käyttäjä ei voi a) vaikuttaa b) edes nähdä.

Tuli testattua äsken toisen journaloivan SSD-levyn irtinyppäys lennosta. Storage Spaces ilmoitti "warning", ja kirjoitusnopeudet itseasiassa nousivat hieman Syynä lienee tuo jäljellejääneen SSD-levyn kytkentä Intelin SATA3-piiriin kun irtinypätty SSD oli Asrockin hivenen heikommassa ja hitaammassa SATA3-piirissä. Molemmat SSD:t lennossa irroittamalla virheviesti oli "error, no resiliency, check the physical drives section" ja kirjoitus levylle estettiin kokonaan. Lukunopeuksiin ei tapahtunut kummassakaan tilanteessa mitään muutosta, ja 5GB testitiedoston luku onnistui myös bittitarkasti virheettä tuolta "error" tilan osiolta.

Tuossa noita ekoissa postauksissa mainitsemiani 20-kertaisia nopeudenmuutoksia ei nyt ihan kuitenkaan sitten tapahtunut oikeassa elämässä, kirjoitusnopeudessa vaan on niin villiä vaihtelua vuorokaudenajan / boottaamisen tai jonkin muun asian suhteen että en ole vielä päässyt kärryille siitä ollenkaan.
Esimerkiksi heti bootin jälkeen Crystaldiskmarkin käynnistys ja 16GB testitiedoston luominen raid-pakalle menee tehtävienhallinnan mukaan jatkuvasti 500-600MB/s vauhtia, ja testi käynnistyykin melko välittömästi.
Toisen testin ajo heti perään vetääkin sitten kirjoitusnopeuden aivan maihin, puhutaan alle 100MB/s kirjoituksista (tuota samaista testitiedostoa asemalle luodessa.) Tuloksiin tuo ei kuitenkaan vaikuta, Crystaldiskmark antaa samanlaisia kirjoitusnopeuksia molemmissa tapauksissa.

 

[jultsu]

Noniin, otetaampa ensimmäiset viralliset testitulokset eikä mitään mutuilunumeroita. Kaikki numerot ovat keskiarvoja kolmesta testiajosta. Ajoin sekä Crystaldiskmark 7.0.0 testin default-presetillä, että kopioin konsolissa Crystaldiskmarkin luoman 64GB randomfill-testitiedoston ja käytin Measure-Command komentoa mittaamaan kulunutta aikaa.

Järjestelmä vielä kertauksen vuoksi: 10x3TB levyt (Dell H200 raid-kortti + emon omat SATA2 liitännät), raid5 (FaultDomainRedundancy 1), 256k interleave, 8 columns, ProvisioningType Fixed, Size 23.82TB, Efficiency 87,49%. 2x Samsung 840Pro 256GB SSD-levyt Journaling-moodissa ja SATA3-liitännöissä.



Osio NTFS formatoituna, SSD-levyt ASMedia + Intel SATA3 kontrollereissa:

[Read]
Sequential 1MiB (Q=  8, T= 1):  1078.476 MB/s [   1028.5 IOPS] <  7762.91 us>
Sequential 1MiB (Q=  1, T= 1):   810.735 MB/s [    773.2 IOPS] <  1291.58 us>
    Random 4KiB (Q= 32, T=16):     8.245 MB/s [   2012.9 IOPS] <220866.24 us>
    Random 4KiB (Q=  1, T= 1):     0.956 MB/s [    233.4 IOPS] <  4279.05 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):   252.051 MB/s [    240.4 IOPS] < 33067.23 us>
Sequential 1MiB (Q=  1, T= 1):   164.226 MB/s [    156.6 IOPS] <  6373.94 us>
    Random 4KiB (Q= 32, T=16):    35.517 MB/s [   8671.1 IOPS] < 48215.79 us>
    Random 4KiB (Q=  1, T= 1):     2.202 MB/s [    537.6 IOPS] <  1838.21 us>

Profile: Default
   Test: 16 GiB (x5) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/01/23 13:32:38
     OS: Windows 10 Professional [10.0 Build 18363] (x64)

PS C:\Windows\system32> Measure-Command {copy C:\Users\Juha-Matti\Desktop\64GB_testfile.tmp q:}


Days              : 0
Hours             : 0
Minutes           : 8
Seconds           : 0
Milliseconds      : 915

avg. 133MB/s

Osio ReFS formatoituna, SSD-levyt ASMedia + Intel SATA3 kontrollereissa:

[Read]
Sequential 1MiB (Q=  8, T= 1):  1096.434 MB/s [   1045.6 IOPS] <  7635.73 us>
Sequential 1MiB (Q=  1, T= 1):   804.745 MB/s [    767.5 IOPS] <  1301.26 us>
    Random 4KiB (Q= 32, T=16):     8.221 MB/s [   2007.1 IOPS] <124818.06 us>
    Random 4KiB (Q=  1, T= 1):     0.926 MB/s [    226.1 IOPS] <  4416.76 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):   258.164 MB/s [    246.2 IOPS] < 32229.42 us>
Sequential 1MiB (Q=  1, T= 1):   172.170 MB/s [    164.2 IOPS] <  6079.46 us>
    Random 4KiB (Q= 32, T=16):    35.796 MB/s [   8739.3 IOPS] < 39508.84 us>
    Random 4KiB (Q=  1, T= 1):     1.542 MB/s [    376.5 IOPS] <  2628.95 us>

Profile: Default
   Test: 16 GiB (x5) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/01/23 16:08:42
     OS: Windows 10 Professional [10.0 Build 18363] (x64)

PS C:\Windows\system32> Measure-Command {copy C:\Users\Juha-Matti\Desktop\64GB_testfile.tmp q:}


Days              : 0
Hours             : 0
Minutes           : 9
Seconds           : 5
Milliseconds      : 90
avg. 117MB/s

Osio ReFS formatoituna, molemmat SSD-levyt ASMedia kontrollerissa:

[Read]
Sequential 1MiB (Q=  8, T= 1):  1115.536 MB/s [   1063.9 IOPS] <  7509.22 us>
Sequential 1MiB (Q=  1, T= 1):   809.938 MB/s [    772.4 IOPS] <  1291.64 us>
    Random 4KiB (Q= 32, T=16):     8.301 MB/s [   2026.6 IOPS] <124307.60 us>
    Random 4KiB (Q=  1, T= 1):     0.968 MB/s [    236.3 IOPS] <  4222.37 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):   158.122 MB/s [    150.8 IOPS] < 52232.77 us>
Sequential 1MiB (Q=  1, T= 1):   110.520 MB/s [    105.4 IOPS] <  9475.19 us>
    Random 4KiB (Q= 32, T=16):    41.122 MB/s [  10039.6 IOPS] < 45800.86 us>
    Random 4KiB (Q=  1, T= 1):     1.269 MB/s [    309.8 IOPS] <  3094.03 us>

Profile: Default
   Test: 16 GiB (x5) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/01/23 18:19:08
     OS: Windows 10 Professional [10.0 Build 18363] (x64)

PS C:\Windows\system32> Measure-Command {copy C:\Users\Juha-Matti\Desktop\64GB_testfile.tmp q:}


Days              : 0
Hours             : 0
Minutes           : 11
Seconds           : 03
Milliseconds      : 09
avg. 97MB/s

TL;DR ReFS ottaa NTFS:ltä turpiin noin 10-15% nopeudessa (tai ainakin isoilla tiedostoilla), lisäksi journalointiSSD-levyjen nopeuteen / kaistanleveyteen kannattaa kiinnittää erityistä huomiota.

Nyt sitten hakkaamaan osiota täyteen varmuuskopioista ja ajamaan ihan oikeita testejä datan eheyttä / vikasietoisuutta testaten.

 

[Yelda]

Kertokaas miten mä puran tälläisen windowsin softalla tehdyn raid kokoonpanon? Yritettiin kaverille asentaa winukkaan vain toiseen kovoon, mutta se ei onnistu koska "näkee" edelleen yhden aseman 460GB yhtenä raid 890GB asemana. Molemmat kovot on nyt koneessa kiinni ja yritän keksiä miten saan tämän purettua.

 

[jultsu]

Kyseessä ei varmaankaan ole Storage Space kyhäelmä, vaan ihan perus Disk Managementin kautta tehty raid0 osio.

Powershellissä komento Clear-Disk pyyhkii levyn täysin tyhjäksi.
Clear-Disk (storage)

 

[Yelda]

Kyseessä ei varmaankaan ole Storage Space kyhäelmä, vaan ihan perus Disk Managementin kautta tehty raid0 osio.

Powershellissä komento Clear-Disk pyyhkii levyn täysin tyhjäksi.
Clear-Disk (storage)

Taas auttoi kun jonnekkin tästä valitti. Sain tuon poistettua yritin vain tehdä sitä väärästä paikasta.

 

[prc]

Omat kokemukset winkkarin raideista:
Raid 1 ja raid 0 ok. Älä edes yritä muita.

Ja Raid1:n tapauksessa tulee disabloida fastboot, koska jos (lue kun) fastboot kusahtaa, niin raid1 tipahtaa fault tilaan ja resync sitten kestää ja kestää.

Lisä hupina jokainen isompi wintendo pätsi veivaa power saving settingsit osittain takaisin defaulttiin -> fastboot enabloituu huomaamatta ja sitten taas syncitään.

 

[jultsu]

Noniin. Siinäpä ei kauaa mennyt kun sain SS:n solmuun.

Piti vaihtaa journaloivat SSD levyt toisiin, ja tein mielestäni ihan ohjeiden mukaan, poistin ensin yhden, lisäsin uuden yhden, poistin toisenkin vanhan ja lisäsin toisen uuden. Harmi vaan että ko. levyt eivät sitten ilmeisesti tykänneet emon SATA-ohjaimesta vaan katosivat näkyvistä hetken päästä, ja koko osio meni offlineen.

Nyt päivää myöhemmin mulla on kuusi SSD-asemaa journaloivana virtualdiskiin kytkettynä, joista neljä on errorissa (retired), kaksi näkyy ihan ok:na, mutta pakka edelleen punaisena eikä suostu tulemaan online. Noita retired SSD-levyjäkään ei pääse millään komennolla poistamaan. Valehtelisin jos väittäisin ettei edes pikkaisen vituta.

 

[mRkukov]

Valehtelisin jos väittäisin ettei edes pikkaisen vituta.

Windows raid on 99% tapauksista huono idea.

Omat kokemukset winkkarin raideista:
Raid 1 ja raid 0 ok. Älä edes yritä muita.

Mutta joo. Paska homma jos et saa datoja näkyviin. Itse vaihdoin lopulta linux nassiin eikä sen jälkeen ole ongelmia ilmennyt.

 

[jultsu]

Juu, osiolla oleva data on muualla kyllä jemmassa, mutta haluaisin yrittää ehjätä tämän vielä enkä vain zäpätä tyhjäksi koko paskaa. Tosin, se tyhjäys olisi kyllä tarpeen, koska valitsin alkujaan vain single parityn, ja osiossa on jo 12 levyä, joten toinenkin pariteettilätty olisi ihan kiva löytyä. Mutta pyritään taistelemaan tämä vielä ehjäksi. Nyt en ole edes varma johtuiko ongelmat rautapuolen yhteensopivuuksista vai saiko SS yksinkertaisesti vain hepulin.

 

[jultsu]

Ja okei. Tulihan se osio taas elävien kirjoihin, kun jumppailin levyjä eri kontrollereihin. SS sallii poistaa vanhat journaloivat levyt pakasta vasta sitten kun ne ovat kiinni pakassa jälleen. Tietää huonoja aikoja tulevaisuudessa jos SSD päättää yhtäkkiä lahota aivan totaalisesti

 

[jultsu]

Paitsi että ilmeisesti ei. Pakka vihreällä, mutta heti kun levylle yrittää kirjoittaa jotain, tulee "Error: Offline due to critical write failure, add drives" ja asema menee offlineen, mutta kaikki kiekot edelleen vihreinä, mukaanlukien journaloivat SSD:t....

Ajelempa tässä nyt testejä ja ilmeisesti tuo ASMedian sata3-kontrolleri on ottanut jotenkin kipeää, tai sitten on joku vielä mystisempi kaapeliongelma kyseessä. HDSentinelillä aloittamani randomdatan kirjoitus/verifiointiajo yhdelle SSD:lle (kiinni ASMedian ohjaimessa) pumppaa ihmeellisesti ylösalas. Ehdin jo vaihtaa kaapeliakin kun ekalla kerralla aloittamani testiajo päättyi siihen että koko levy katosi Windowsista noin 10% kohdalla. Nyt ollaan jo yli puolenvälin päästy, mutta tasaisesti dippailee ylösalas käyrät.

edit. ja monologi jatkuu... ostin ilmeisesti kasan paskaa tältä foorumilta, neljä 120GB Samsung 840 EVOa joista vain yksi suostuu edes jotenkin toimimaan, kaksi noista ei enää tunnistu ollenkaan ja yksi pumppaa tuota nopeutta ylösalas. Samoilla johdoilla samaan ASMedian ohjaimeen kytkettynä normaalit HDD:t toimii ongelmitta.

 

[mRkukov]

edit. ja monologi jatkuu... ostin ilmeisesti kasan paskaa tältä foorumilta, neljä 120GB Samsung 840 EVOa joista vain yksi suostuu edes jotenkin toimimaan, kaksi noista ei enää tunnistu ollenkaan ja yksi pumppaa tuota nopeutta ylösalas. Samoilla johdoilla samaan ASMedian ohjaimeen kytkettynä normaalit HDD:t toimii ongelmitta.

Onko käytössä kunnon sata kaapelit? Huono kontakti ei olisi ekaa kertaa ongelmana. Mikä poweri koneessa? Huono poweri voisi hyvin tappaa/sekoittaa levyjä urakalla.

 

[jultsu]

Iciwanha Super Flowerin 500W Passive, mutta en usko että tuo olisi tappanut nuo vastikään ostamani kiekot, varsinkin kun koneessa pyörii edelleen luotettavasti muitakin ssd:itä ja 12kpl 3.5" limppuja myös.

Kyllä noille "rikkinäisille" levyille pystyy asentamaan käyttiksen läppärissä ja käyttämäänkin ihan ok, siellä ei mitään ongelmia. Kokeilin tässä pöytäkoneessa kaikkia neljää levyä kolmella eri sata-ohjaimella (ja useammilla kuin kolmella eri kaapeli/virtajohto-yhdistelmillä) ja jälleen kerran kaikki tunnistuivat (tällä kertaa Intelin SATA2 ohjaimessa) mutta pidempiaikaisessa kuormituksessa tipahtivat sitten kaikki pois.

Kyllä tuo SS osio nyt on jotenkin royally fucked. Vaikka mitä noiden journalointilevyjen kanssa puljaisi, en saa kirjoitettua enää osiolle. Lukutilassa tuon saa kyllä luotettavasti mountattua joka kerta, eli pitää sitten tehdä osion zäppäys ja luoda uusiksi, tällä kertaa kahdella journalointilevyllä niinkuin suunnitelmissa olikin. Ei vaan vala kovin paljoa uskoa tähän SS:ään tulevaisuutta ajatellen, mutta hei, teknologiademona ja oppimiskokemuksena tätä lähdinkin käyttämään.

 

[jultsu]

Storage Spaces: 1 - jultsu: 0

Vittu. Bootin jälkeen en enää saanut osiota edes lukutilaan. Siispä koko paska tyhjäksi ja uudestaan.

Spoileri: No, näistä oppii.

Kaikki muut paitsi Microsoft.

 

[jultsu]

Ja lisää huomioita Storage Spacesista....

Luon nuo osiot aina Win10Pro 1703 versiolla, koska se oli viimeisin käyttis jolla sai ReFS osioita formatoitua. Tämän jälkeen pakan voi avata pääkäyttiksen puolella (tällä hetkellä 1903) ja konvertoida sen uudempaan muotoon, joka taasen rikkoo yhteensopivuuden tuon 1703 version kanssa.

Koitin eilen luoda 8x3TB raid6 osion ensin, ja sen jälkeen lisätä 3x 120GB SSD-levyt journaloimaan suoraan, mutta tämä ei aktivoinut noita ssd-levyjä käyttöön ollenkaan.

Nyt loin taas uudestaan osion, ja tällä kertaa lisäsin nuo ssd-levyt suoraan mukaan muidenkin levyjen matkassa (datalevyiksi siis) ja vasta sitten tägäsin ne "Journaling" moodiin pakassa. Tämä aktivoi ne journaloimaan. Koska miksi? Storage Spaces!

 

[mRkukov]

Tätä saagaa on jotenkin "hauska" seurata vierestä, kun joskus tappelin itsekin tuon roskakasan kanssa. Pisteet kyllä yrittämisestä, etkä ole vieläkään luovuttanut.

 

[jultsu]

Juuh, tässähän tätä oppii, voi näitä tietoja ja kokemuksia ehkä tarvita joskus tulevaisuudessakin ja onhan tämä pakosti nyt jo paljon käytettävämpi ratkaisu kuin joskus 2012 julkaisun aikoihin vaikka ei kokemusta niiltä ajoilta olekaan (aloitinkin vasta kuukausi sitten tämän kanssa leikkimisen.)

Nuo 120GB ssd-levyt olivat nyt se syyllinen tuohon edellisen pakan hajoamiseen, ilmeisesti journaloivatkin levyt lasketaan mukaan pariteettiin eli jos molemmat journaloivat kiekot tippuvat samaan aikaan pois (niinkuin tuossa kävi), ei osio pysty palautumaan enää tuosta virheestä. Tai sitten SS sai jonkun randomhepulin. Pitää vielä testata uudestaan nyt raid6 moodissa että kuinka käy jos kaksi ssd:tä rykäisee irti ja iskee jotain muuta tilalle, tällöinhän jää vielä kolmas ssd journaloimaan.

 

[jultsu]

Joo, sain ainakin nyt pakan vielä takaisin vihreälle tuon yhden hepulin jäljiltä kun kaikki kolme journaloivaa ssd:tä tipahtivat pois näkyvistä. Irroitin yhden koneen ollessa sammuksissa ja lisäsin alkup. 250GB ssd:n sen tilalle, ja bootattua windowsiin Storage Spaces kertoi yhden levyn olevan kateissa.

Komennolla $add = Get-PhysicalDisk -SerialNumber S1ATNSADC15767Z saadaan tuo kytkemäni 250 gigainen 840 Pro SSD lisättyä ympäristömuuttujaan $add, jotta se voidaan lisätä myöhemmin pakkaan komennolla Add-PhysicalDisk -StoragePoolFriendlyName kakka -PhysicalDisks $add -usage journal

(Storage poolin nimi on siis kakka.)

Seuraavaksi pitää tietää kadonneen levyn uniikki tunniste jotta se merkitä poistetuksi käytöstä ja näin ollen poistaa kokonaan pakasta.
Komennolla Get-PhysicalDisk | ft uniqueid, friendlyname, serialnumber saadaan näkyviin levyjen yksilöllinen tunniste, joka poistettujen levyjen / duplikaattien tapauksessa on vähän eri muotoa kuin normaalisti:

Nyt siis muutetaan tuo puuttuva levy "retired" tilaan komennolla Set-PhysicalDisk -UniqueId "{ff126aad-ec3b-2cf6-9e7d-997af2edb33c}" -Usage retired

Nyt näkymä on tämänlainen:

Tämän jälkeen levy voidaan potkaista kokonaan pois pakasta, lisäämällä levy ensin muuttujaan $paska komennolla $paska = Get-PhysicalDisk -UniqueId "{ff126aad-ec3b-2cf6-9e7d-997af2edb33c}" ja tämän jälkeen komento Remove-PhysicalDisk -PhysicalDisks $paska -StoragePoolFriendlyName kakka potkaisee levyn kokonaan, GUI muuttaa väriään keltaisesta taas vihreäksi, ja alles klar, alles gut.

 

[Zetteri]

Itselläni on RAID 5 pakka tehtynä Windows Server 2016:ssa ja myöhemmin importattu Windows Server 2019:n.
Lättyinä on vaan 4kpl 1TB WD Blackejä.
Ja tässä yksi noista nykyään jo hälyyttelee kunnostaan ja tila on muutenkin lopussa.
Niin olen ajatellut hommaavani 4kpl joko 3TB tai 4TB Siikakeitin Ironwolfeja tilalle.
Että varmaan helpoimmalla pääsee kun luon noilla uusilla uuden raid 5 pakan ja sitten siirtää kaiken datan vanhalta pakalta.

Kun suoraan ei vissiin voi vaihtaa yksitellen noita 1TB lättyjä isommiksi?
Kysyn tätä koska ei ole aikaisemmin tarvinnut vaihtaa raid pakkaan levyjä.

Edellisillä kerroilla olen aina rakentanut kokonaan uuden setin ja siirtänyt kaiken datan verkkoa pitkin vanhasta boksista.
Myöskin aikaisemmin käytin ensin FreeNASia mutta se oli liian rajoittunut, joten vaihdoin OpenMediaVaultiin ja sillä oli tapana hukata ZFS raid pakka ja rikkoa siinä samassa aina PLEX Media Serveri.

Sitten kokeilin Windows Server 2016:sta ja sillä tiellä ollaan vieläkin.
Kun kone hoittaa nykyään:
-NAS
-Reititin (Dhcp ja DNS)
-Palomuuri
-Plex Media Serveri
-Yläkerran pelikonsoli
-Alakerran HTPC:lle pelien striimaus kone (Steam home Steaming)