Paljon on tullut luettua noista, mutta täältä annan kyllä hiukan eriävän mielipiteen. Itselläni on kaksi pöytäkonetta lähes 24/7 päällä. Nyt puolen vuoden sisään ovat ryssineet tuolla sähköverkossa tällä alueella jotain varsin tiuhaan ja sähköt on katkenneet lennosta nyt noin 40 kertaa puolen vuoden sisään. Joka kerran jälkeen on koneet palautuneet, eikä ole tullut mitään SSD vaurioita.
Just just, kylläpä on massiivinen otos ja seuranta.
Ensinnäkin kaksi levyä on ihan liian vähän, toisekseen, 40 katkoa on ihan liian vähän (tilastollisesti, ei ongelmien aiheutumisen kannalta). Sekä viimeisekseen mikä on ollut levyjen käyttötilanne kun katko tapahtui? Nämä kaikki asiat käsiteltiin erinomaisesti tuossa SSD levyjen luotettavuusartikkelissa.
A) Datan pitää olla sellaista, että tiedät edes levyn korruptoitumisesta
B) Levylle pitää olla aktiivisia kirjoituksia, mieluiten randomina, pienillä blokeilla ja satunnaisessa järjetyksessä, QD32.
C) Virran katkaisun jälkeen pitää tarkistaa, tapahtuiko korruptoitumista.
Jos levylle ei kirjoitettu, data on sellaista ettei korruptoitumista huomaa tai virrankatkeamisen aikaan ei kirjoitettu. Niin se ei tarkoita sitä etteikö ongelmaa olisi olemassa, vaan sitä, ettei sitä havaittu. Just tällasista asioista mä saan säätää ns. ingenjöörien kanssa joka päivä. Kun ne väittää että se, että testataan jotain asiaa sata kertaa on ikään kuin todiste, siitä, ettei ongelmaa ole olemassa. Ei, kävikö mielessä sitä, että testaus menetelmä tai ympäristö voi olla virheellinen,eikä ongelmaa näin ollen vain saatu toistettua?
Todellakin, noita ongelmia oli kaikissa SSD levyissä paitsi vain kalleimmissa. Joissain niitä oli jopa todella massiivisessa mitta kaavassa, eli noista rinnakkaisista kirjoituksista, monta korruptoitui, eikä vain esim yksi ainoa.
Pahimpia ongelmia oli osittain kirjoitetut blokit. Kyllä ihan oikeasti. Esin. koko 4 KB blokki on täynnä AAAA:ta, ja se halutaan täyttää BBBB:llä. Kuitenkin virran katkaisun äjlkeen tuo 4 KB blokki voi olla 1024 tavun verran B:tä ja loput 3072 tavua A:ta... Tuosta ei taatusti mikään normaali ns. recovery järjestelmä toivu, koska tilanteen ei lähtökohtaisesti pitäisi olla tuollainen. Toinen vaihtoehto on esim se, että tuo koko blokki jota oltiin kirjoittamassa on täynnä ihan jotain randomia koska FTL layerin address mapping meni sekaisin virrankatkeamisen takia. Varsinkin tuo osittain kirjoitettujen blokkien ongelma ei tule ilmi, riippuen datasta, ellei sitä tarkisteta. Eli katkon jälkeen koko levyn sisältö pitää tarkistaa ja valitoida. Muuten tapahtuu sitä kaikkein vaarallisinta sorttia, eli piilokorruptoitumista. Tiedot on levyllä jo vähän sekaisin, mutta et vain tiedä siitä. Henkilökohtaisesti suhtaudun tuollaisiin ongelmiin erittäin vakavasti. Mikä kaikkein kurjita, Flash tekniikan vuoksi, tuo piilokorruptoituminen koskee myös dataa, jota et ollut käsittelemässä. Eli ne tiedostot joihin et ole koskenut kahteen vuoteen, voivat yllättäen korruptoitua, vaikka et koskisi niihin lainkaan. Jos nyt otat noista varmuuskopion, vanhan päälle, korruptoit myös varmuuskopiosi.
Eri tasoilla syntynyt piilokorruptoituminen oli joskus varsin normaalia mm. P2P verkostoista ladattujen DIVX ja XVID videoiden kohdalla. Niissä saattoi olla bittivirheitä sillä täällä ja tuollaisessa pakatussa video streamissa ne huomasi vaikka yleensä eivät estäneet ohjelman katsomista. Mutta eihän niitä virheitä pitäisi lähtökohtaisesti edes olla? Kun nuo virheet sattuu väärään paikkaan, sitten onkin iso ongelma edessä.
Joskus olen kysynyt näiltä samoilta insinöörieltä, että onko teistä ok jos. Vedän nyt puukon taskusta ja huidon sillä sillä satunnaiseen suutaan. Jos kukaan ei kuole, niin mitään ongelmaa mun toimenpiteiden kanssa ei ole, eihän? Eli reagoidaan vain vakaviin seurauksiin, eikä mahdollisuuteen siitä, että jotain vakavaa voisi em. asian johdosta tapahtua. Tyypilinen (mutta varsin normaali) virheellinen tapa käsitellä riskiä. Jos sitten vähän nirhasenkin jotain tyyppiä sillä veitsellä, niin nou problem, vähän vaan paikkaillaan sitä ja kaikki on taas ok. Kannattaa tutustua mm. root cause analysis ja five whys aspekteihin.
Esimerkkinä
tämä ongelma, jonka korjasin mun koodista. Tyhmempi olisi voinut väittää että. Ohjelma toimii oikein. Ja että syynä oli levyjärjestelmän ongelmat ja koneen sammuttaminen väärin. Mutta kun oikein toimiva ohjelma ei saisi mennä sekaisin noissakaan tapauksissa. Siksi korjasin ohjelman. Kun ongelmia ei haluta tunnistaa, eikä korjata, niin se on taattu tapa varmista se, että ongelmista ei koskaan päästä eroon. Tuokin huonosti tehty ohjelma on toiminut lukemattomilla asiakkailla vuosia ilman ongelmia, ennen kuin tuo ongelma ilmeni. Takana on siis kymmeniä miljoonia onnistuneita suorituksia. Mutta se ei tarkoita sitä, että ohjelma olisi toimiva. Tuo os.fsync on tuolla sen takia välttämätön, että joissain ympäristöissä on käytössä data=writeback joka edelleen sallisi sen, että tuon uuden tiedoston data ei ole levyllä, vaikka tiedoston metadata on. Fsyncin käyttäminen varmistaa myös sen, että itse data on levyllä. Muuten taas tulisi sellainen tilanne eteen, että koodi näyttää oikealta, mutta voi juuri tietyissä tilanteissa ja ympäristössä, edelleen toimia väärin.
Nuo asettaa mm. tiedostojärjestelmän (joka on itseasiassa siis tietokanta) ja tietokantojen suunnittelijoille ihan oman luokan haasteita. Koska levy ei välttämättä toimi niin kuin sen oletetaan toimivan. Vaan chekien ja tarkistusten pitää olla paljon syvällisempiä.
Tämä on mm. yksi syy, miksi data checksumeista ja copy on writestä on puhuttu niin paljon. Ne ovat menetelmiä jotka suojaavat osittain tuota ongelmaa vastaan. Mutta, eivät nekään ihmeitä tee, varsinkin FTL korruptiota vastaan on aika mahdotonta taistella sovellustasolla.
Kannattaa katsottaa journalointiin ja tiedostojärjestelmiin ja luotettavuuten liittyvät esitykset täältä:
https://www.usenix.org/conference/fast13/
Aihe: SSD levy jumittaa kaiken (Luettu 10271 kertaa)
