Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Laitealue => Aiheen aloitti: jimbo - 02.12.13 - klo:23.18
-
12.04LTS
palikat on vajaa 2v vanhat, uutena ostettu:
asus F1A75-M PRO
https://www.asus.com/Motherboards/F1A75M_PRO/#specifications
AMD APU A4 X2 3400 FM1 tuplaydin with Radeon HD6000
muisti 1x4Gb DDR3/1600 kingston
alle vuoden vanha uutena ostettu SSD sandisk ready cache 32Gb eli iso levy ;)
muut palikatkaan ei ole kovin vanhoja, toimi tähän päivään asti ok, kunnes...
(tätä ennen toiminut ok eikä mitään oireita tai ongelmia, levytyökalulla katsonut alussa SSD:n tietoja ja ollut ok, ei ole katsonut viime kuukausina kun ei ole ollut ongelmiakaan, levy päivittäin koko päivän lähinnä net surffaus käytössä)
kun pani käyntiin ruutuun tulee:
the data in the EC or EC flash might be corrupted. contact asus support (!!!) >:( ??? :-\ :-\
ja menee itestään kiinni 15s päästä
pari kertaa uudelleen, sama tulos, ei päästä edes bios ja vaikka kaikki irti ei siltikään päästä edes bios. myöhemmin päästi kun ei mitään buuttaavaa kiinni. SSD nyt irti ja voi kokeilla live levyllä toisessa pöytäkoneessa. kun on kiinni ajatteli ensin katsoa levytyökalulla mitä sanois ja sitten toivottavasti! päästäis suoraan dataan käsiksi! vielä ei ole uskaltanut, jos saisi ensin kommenttia tilanteeseen
"jos ja kun ssd hajoaa, niin paljon useammin käy: kaikki tiedot menetetään, hajoaminen voi olla salakavalan hidasta. tai hajoaa sen enempää ilmottamatta" jne. löysi mainintaa pika etsinnässä
entä verrattuna wintoosan defragment mitä teki aikanaan IDE/SATA levyille, miten SSD levyn korruptio ? kertyy myös ajan myötä ? ja pitäisi poistaa ? kuinka helppo on ubuntussa ? eli käytänössä yksi komento vai säätämistä eli monta komentoa ? (toinen tapa olisi win 7, ei ole sitä paljoa käyttänyt kun ei wintoosaa enää 2005 jälkeen)
SSD:n "luotettavuus" !!! kun ei ole liikkuvia osia ja toinen on nopeus, syyt miksi osti
mutta ensin olisi tämä korruptio ja dataan kiinni pääsy... :-\
-
entä verrattuna wintoosan defragment mitä teki aikanaan IDE/SATA levyille, miten SSD levyn korruptio ? kertyy myös ajan myötä ? ja pitäisi poistaa ? kuinka helppo on ubuntussa ? eli käytänössä yksi komento vai säätämistä eli monta komentoa ? (toinen tapa olisi win 7, ei ole sitä paljoa käyttänyt kun ei wintoosaa enää 2005 jälkeen)
Tässä tulee esiin oikeasti hyvän SSD:n ja pilipalivehkeitten ero. Kunnollisissa asemissa on sen verran hyvä kontrolleri, että se hoitaa homman itsestään. Ainoa asia mikä on hyvä pitää mielessä aina on, että tyhjää tilaa pitää olla käytännössä se +10% aseman tilavuudesta tai kärsii sekä suorituskyvyssä, että aseman eliniässä. Esim. Samsungin 840 sarjassa voi heti apuohjelmasta määritellä, että tuo suositeltu tila piilotetaan kokonaan järjestelmältä. Nykyään edes Windows maailmasta tutumpi Trim ei ole varsinaisesti mikään pakollinen toiminto SSD-asemille, vaan pätevät asemat tosiaan tekee "garbage collection" ominaisuuden ominpäin.
SSD:n "luotettavuus" !!! kun ei ole liikkuvia osia ja toinen on nopeus, syyt miksi osti
Ei pahalla, mutta halvalla ei tuuppaa samaan mitään hyvää.
Tuo asema on luokiteltu nimensä veroisesti välimuistiasemaksi kiintolevyn kaveriksi. Voi hyvin kuvitella, että tuollaisille ei lupailla kovin paljoa kirjoituskertoja. Ainakin oman käsitykseni mukaan tuossa tulee Windows softa mukaan, jolla ilmeisesti ajetaan ne "ydin palikat" vain tuonne asemalle käynnistyksen nopeuttamisen toivossa.
En tiedä. Todella monet kehuu Sandiskia merkkinä ja onhan se todella iso merkki. Ei siinä mitään. Mutta henk.kohtaisesti en pidä niitten tuotteita kyllä yhtään minään. Lähes poikkeuksetta jos jokin SD-kortti tms. kajahtanut täysin yllättäen, niin poikkeuksetta päällä on tuntunut lukevan Sandisk.
-
ok eli ei liene ihan paras mahd. sen tiesi jo hankkiessa, auki on pääseekö dataa lukemaan suoraan (mielipide/mahd. ongelmat ?) ja miten defragment nyt kannattaisi tehdä ? ja jos datat ensin kopioi turvaan niin tehdä filejen defragment muualla ? entä ssd levyille yleensä defragmentin tekeminen kuinka usein ? jopa arviota ko. levyn kesto iästä ? joka päivä back uppia... ;)
eri merkeistä ja malleista on varmaan yhtä monta mielipidettä kuin on mielipiteen esittäjiäkin, monenlaista on nähnyt, juuri osti sandisk muistikortteja videokameraan, ei ihan perusmalli, saas nähdä koska onkelmat ;) tämä tästä
-
Mä veikkaisin että sun koneen bios on korruptoitunut. Jos et pääse edes biosiin.
-
päästi jo eilen bios, on näköjään tullut viime kuun alussa 1 uudempi versio: Improve system stability, tulis varmaan päivittää, mistäs näkis onko nykyinen bios ok tai se olis (osa?) syy ongelmiin ?
nyt päästää levylle normaalisti, backuppi kaikesta otettu tikulle, live cd:llä näyttää levyn mutta ei päästä fileihin käsiksi käyttöoikeuksien takia, vanha homma
nyt vapaana 17Gb, koko ajan on ollut lähemmäs/ylikin 50% vapaana min ainakin 30% vapaata koko ajan
käyttöä n. 70päivää, hieman yli 500 käynnistystä, kaikki virheet nollassa tai n/a, ECC count 23, kasvoi 22->23 backupin oton aikana
-
Memtest kannattaa myös ajaa läpi. Itse testailen tavallisesti poissulkevalla menetelmällä eri komponentteja. Joku täällä osaa varmasti tulkita lokitiedostoja, joista saattaisi selvitä, mikä osa koneestasi kaataa järjestelmän.
-
Ainoa asia mikä on hyvä pitää mielessä aina on, että tyhjää tilaa pitää olla käytännössä se +10% aseman tilavuudesta tai kärsii sekä suorituskyvyssä, että aseman eliniässä.
Mielenkiintoista, viittaatko tällä tiedostojärjestelmään vai levyn kapasiteettiin? Molempien kanssa täyttymisestä on omat harminsa. Mutta siis kunnon levyissä on aina reilu over-provision, eli vaikka levy olisi muka täynnä, niin ei se sitä oikeasti ole. Tuota samaa over provision tilaa voidaan myös muutenkin hyödyntää olennaisesti pitkkittämään ikää siinä vaiheessa kun osa alueista alkaa virheilemään. Enterprise levyissä voi olla jopa yli 20%. Eli myyvät esim teran kapasiteetilla varustetun levyn 800 gigasena ja 128 gigasen levyn 100 gigasena jne.
Tuo on myös eritäin tärkeää sellaisissa tilanteissa joissa trimmiä ei päästä käyttämään ollenkaan, syystä tai toisesta.
-
Mielenkiintoista, viittaatko tällä tiedostojärjestelmään vai levyn kapasiteettiin? Molempien kanssa täyttymisestä on omat harminsa. Mutta siis kunnon levyissä on aina reilu over-provision, eli vaikka levy olisi muka täynnä, niin ei se sitä oikeasti ole. Tuota samaa over provision tilaa voidaan myös muutenkin hyödyntää olennaisesti pitkkittämään ikää siinä vaiheessa kun osa alueista alkaa virheilemään. Enterprise levyissä voi olla jopa yli 20%. Eli myyvät esim teran kapasiteetilla varustetun levyn 800 gigasena ja 128 gigasen levyn 100 gigasena jne.
Tuo on myös eritäin tärkeää sellaisissa tilanteissa joissa trimmiä ei päästä käyttämään ollenkaan, syystä tai toisesta.
Pääsääntöisesti tiedostojärjestelmän tilavuudesta ainakin vanhemmilla SSD-asemilla. Muistaakseni ainakaan vanhat Kingstonit ja eikä taida vielä tuossa Vertex 3:ssa myöskään olla oikein kunnolla tuota over-provisionia hyödynnetty. Tosin nyt kun laitoin pöytäkoneeseen Samsungin 840 Pron, niin siinä valmistajan ohjelmilla voi heti määritellä järjestelmältä näkymättömäksi tuon over-provision osan. Jos oikein käsitin, niin firmware tasolla siinä on kait ihan minimalistisen vähän valmiiksi määriteltynä sitä, mutta apuohjelmalla saa otettua sen oikein kunnolla käyttöön, sekä siis varmistettua, että sille tilalle ei varmasti sitten kanssa kirjoiteta mitään. Sinänsä aika syrjimistä heidän kannalta, että mielestäni Linuxin vastaavista ominaisuuksista/apuohjelmista en huomannut mitään mainintoja. Kyseessä oli siis Windows kone.
Oikein kunnon Enterprise levyissä tuo on varmaan hoidettu jo suoraan firmware-tasolla, eli apuohjelmia ei varmaan käytetä kuin asemien kunnon tarkkailuun. Eikös niissä tapahdu myös trimmit yms. jo ihan rautatasolla? Käsittääkseni tuo Samsung tekee jo joitain optimointeja suoraan ohjauspiirillä. Tosin ovat varmaan varsin alkeellisia tekniikoita Enterprise luokan asemiin. Nehän nyt yleensä onkin hinnaltaan moninkertaisia vrt. kuluttajalevyihin samalla tilavuudella.
*lisäys*
Oli tuo samppakin muistaakseni hiukan pienempi mitä "paperilla" lukee. Siis jo ilman tuota apuohjelmaa, eli sehän varmistaa jonkinlaisen over-provisioning osuuden asemasta.
-
SSD levyjen luotettavuus on tunnetusti huono, ei siinä ole mitään ihmeellistä. Tutkittua faktaa, kannattaa katsoa mm. tämä:
https://www.usenix.org/conference/fast13/understanding-robustness-ssds-under-power-fault
Totesivat suoraan, että ns. kuluttajalevyissä ei tainnut olla yhtään ainoaa luotettavaa levyä. Pelksätään jo virran katkaisu levystä sekottaa monet levyt mitä kuluttajille myydään, koska niissä ei ole asianmukaista suojausta asian hoitamiseksi. Tilastot ovat tylyä katsottavaa.
Ei siis auta vaikka tiedostojärjestelmä olisi luotettava, vaan SSD itsessään sotkee tiedot. Tuo samahan voi toki käydä mm. writeback levyohjaimen kanssa, jos kirjoitus cache ei ole write-through tilassa. Mutta yleensä noiden ohjaimien kanssa sittne käytetään omia akkuja / pattereita, jotka hoitavat sen cachen tyhjentämisen levylle, siinä tilanteessa että virta katkeaa yllättäen.
Sinänsä nuo SSD ongelmat eivät varmaan tule kenellekään yllätyksenä. Nopeus ja halpa hinta, eivät kulje oikein käsikädessä luotettavuuden kanssa, ja tämähän on ihan vanha fakta. Kun ruvetaan oikomaan mutkia, saadaan vauhtia ja luotettavuus laskee. Tuossa testissäkin totesivat, että ainoat levyt jotka toimivat kunnolla olivat kunnolliset SLC SSD:t, joissa taisi olla giga hinta jotain ~5€/giga.
Olen tässä juuri taistellut eräiden insinörttien kanssa siitä, että voiko ja saako tietokannat mm. korruptoitua jos ohjelmaa / järjestelmää ei suljeta oikein. Mielestäni ei saisi. Jos vain transaktiot, journalling, barrierit ja ordering pidetään oikeana. Jos on jotain mitä ei ole komitattu, niin sitten roll backätään. Mutta korruptoitumista EI saisi tapahtua. Nyt tämä tutkimus osoittaa, että mm. Sekunda SSD levyjen kanssa, ei ole mitään hyötyä siitä, että tietokanta, tiedostojärjestelmä ja käyttöjärjestelmä toimii oikein, kun kerran levy itsessään ei toimi oikein.
Tässä listattuna muutamia hienoja tapoja sotkea tiedot:
https://www.sqlite.org/howtocorrupt.html
-
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.
Tosin UPS:n on kyllä kovasti harkinnassa, luonnollisesti.
-
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 (http://www.sami-lehtinen.net/blog/chaos-monkey-bit-me-a-short-story-about-transactionality), 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/
-
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.
Joopa joo.Niin meinaat että on ihan täysin normaalia kotikäyttäjille, että puolen vuoden sisään tulee sen about 80kpl yllättäviä sähkökatkoja pöytäkoneeseen. Monissa tapauksissa ei ollut mitään kirjoitusta levylle. Mutta kerro keskivertokäyttäjät jotka tallentaa _kokoajan_ tietoa asemalleen. Yhden katkon pääsin näkemään juuri Windowsin päivitysten aikaan ja silloin ajattelin, että nyt tuli ongelmia, mutta ihme ja kumma kyllä homma toimi senkin jälkeen.
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ä.
No tuo toki liittyy aiheeseen kovasti. Verkkosiirtotekniikka ja massamuistitekniikka nehän kulkee ihan käsikädessä. ::)
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.
Siis mikä käyttöjärjestelmä ei tuota tee oletuksena?? Itsellä ei tule mieleen yhtään käyttistä mihin ei jätetä "lippua", että järjestelmä on suljettu oikein. Jaa no Amigassa tuota ei kyllä tainut vielä olla.
Minä vain totesin, että normaalikäytössä ihmisiä pelotellaan aivan liian paljon tuolla aiheella. Suoraan sanottuna meikäläistä ei kiinnostakaan pätkääkään miten jotenkin palvelimen tai isojen tietokantojen pitäjälle käy. Käsittääkseni tämä ketju ei alunperin liity mihinkään kaupallisen tason rautaan. On se kumma jos ei omia kokemuksiaan saa tänne kirjoittaa.
Mutta ei siinä mitään. Varmuuskopioista kannattaa pitää huolta. En toki väitä etteikö SSD voisi kuolla sähkökatkoissa. Niinhän kiintolevykin voi tehdä. Jos haluaa elää jatkuvassa pelossa ja teoreettisessä elämässä, niin antaa palaa.
-
Joopa joo.Niin meinaat että on ihan täysin normaalia kotikäyttäjille, että puolen vuoden sisään tulee sen about 80kpl yllättäviä sähkökatkoja pöytäkoneeseen.
En, mutta se on täysin mahdollista, että kun sellainen tapahtuu, niin se sotkee tietoja jos kirjoitus on juuri sopivassa kohdassa ja vielä useammalla eri tasolla. Kuluttaja SSD levyillä ja myös tiedostojärjestelmä tasolla.
Siis mikä käyttöjärjestelmä ei tuota tee oletuksena?? Itsellä ei tule mieleen yhtään käyttistä mihin ei jätetä "lippua", että järjestelmä on suljettu oikein. Jaa no Amigassa tuota ei kyllä tainut vielä olla.
Niin, siis tuo tarkistus minkä käyttikset tekee, tarkistaa vain ja ainoastaa metadatan, itse levyn dataa ne eivät tarkista. Tämän lisäksi, mm. ext2 ei sisältänyt journalia oletuksena edes metadatalle. Eikä mm. fatit tee sitä edelleenkään, pois luktien TFAT. Mikään näistä ei tarksita dataa, vain metadatan. -> Korruptoitumista ei havaita oletusarvoisesti. Mikäli korruptoituminen tapahtuu FTL tasolla tai muulla SSD:n teknisellä sisäisellä tasolla, ei sitä myöskään huomata tiedostojärjestelmän puolella lainkaan. Siis voidaan huomata virheellisenä datana, sitten kun se luetaan, mutta oletusarvoisesti mitään tietoa siitä ei tule. Eikä sitä virheellistään dataa tunnisteta käyttiksen toimesta, vaan vasta sitten sovellus potkaisee tyhjää / valittaa tiedoston olevan rikki / näyttää väärää infoa.
BtrFS cow modessa ja data checksumeilla ja datan journaloinnilla hoitaa homman kyllä kotiin, mutta nuo eivät ole oletusasetukset.
Ext4:n voi myös määritellä journaloimaan data journal=data mount optiolla.
Mutta ei siinä mitään. Varmuuskopioista kannattaa pitää huolta.
Juuri tähän kohtaan se piilokorruptoituminen pureekin kaikkein kurjimmalla mahdollisella tavalla. Sulla on esim joku salattu tiedosto koneella, jonka olet pakannut ja testannut jossain vaiheessa. Sitten se tiedosto korruptoituu hiljaisesti, ja otat siitä varmuuskopiot. Nyt sulla on rikkinäinen varmuuskopio myös. Kun sitten jossain vaiheessa koitat purkaa sitä, niin koko file on rikki, koska salatut tiedostot eivät pääsäntöisesti kestä yhtään korruptoitumista.
Tätä vastaan tietysti voi taistella mm. par2 sovelluksella. Mutta se taas on ihan liian hidas ja raskas menetelmä ns. normikäyttöön, vaikka varmuuskopioiden kanssa sitä käytänkin.
Tämän takia ns. staattisesta datasta pitäisi luoda heti lähteellä varmuuskopio, eikä sen jälkeen enää päivittää sitä, mm. järjestelmän levyltä.
Eli valokuvista ja videoista kopiot suoraan kamerasta, eikä mm. kerran kuussa koneen kiintolevyltä ulkoiselle levylle.
Sori jos viilaan pilkkua, mutta pitää tietää miten asiat on, jotta voi varautua mahdollisiin ongelmiin ja tietää miten niitä torjutaan.
Edit: Monesti ns. normaali koneen tai komponenttien kuolema virtakatkon yhteydessä liittyy jännitepiikkiin. Mutta siitä ei ole tässä kyse. Ja palvelimien tapauksessa siihen, että levy on voinut pyöriä viimeiset neljä vuotta nonstoppina ja jäähtymisen jälkeen sen laakerit / mekaniikka / elektroniikka ei nää toimi kuten olisi tarkoitus. Onneksi näitä instant kuolemia on perinteisillä levyillä ollut aika vähän. Yleensä ongelmat ilmenee lukuvirheinä ja joskus jopa saattaa saada SMART varoituksen ajoissa.
Btw. Mulla oli joskus digikamerassa sellainen compact flash kortti, joka sekosi aina kun akku meni melkein tyhjäksi ja sitten sinne yritti tallentaa jotain. Tämä on loistava esimerkki siitä, miten homma ei saisi toimia. Eli kamera toimi vielä, mutta SD kortti sekosi aina. Piti muistaa että kun tulee eka patterivaroitus, niin sen jäkeen ei taatusti oteta enää kuvia, tai jo otetut kuvat tuhoutuu. Tuossa siis jännitteen lasku riitti ongelmiin, eikä tarvittu virtakatkoa.
-
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.
Siis mikä käyttöjärjestelmä ei tuota tee oletuksena?? Itsellä ei tule mieleen yhtään käyttistä mihin ei jätetä "lippua", että järjestelmä on suljettu oikein. Jaa no Amigassa tuota ei kyllä tainut vielä olla.
Eiköhän Amigassakin levyntarkistukset hoideta asiallisesti.
http://www.amigaos.net/
-
Puhuinkin perinteisestä Amigasta, enkä AmigaOS:stä.
-
Puhuinkin perinteisestä Amigasta, enkä AmigaOS:stä.
Ja Amiga OS on Amigan käyttöjärjestelmä ???
-
Tuolla linkkisi AmigaOS:llä ei ole yhtään mitään tekemistä sen perinteisen AmigaOS:n kanssa. Kuten huomaat sen nimi on AmigaOS 4
-
Anyway, tässä vielä linkkiä faktaan, ettei vaan huulet heilu. Suosittelen tutustumaan, asiallista settiä ja huolella tehty.
Understanding the Robustness of SSDs under Power Fault (https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf)
Nyt kun tuon luin uudestaan läpi, niin mielestäni en ole sanonut mitään väärin. Sekä totean vielä, että nuo unserializable writes SSD tasolla johtavat myös helposti journaloivan tiedostojärjestelmän korruptoitumiseen, koska kirjoitukset SSD levylle eivät todellisuudessa tapahdu siinä järjestyksessä mitä käyttöjärjestelmä niitä antaa. Tässä yhteydessä tietenkin barrirers=1 optio (joka on oletus) voi mahdollisesti auttaa. Koska silloin NCQ jonon käyttö estetään kriittisissä kohdissa. Oletan kuitenkin että tuon tason tutkimuksessa ottivat tuon huomioon, ja siitä huolimatta SSD puskuroi kirjoituksia (eli kuittaa ne tehdyksi, vaikka niitä ei ole todellisuudessa vielä tehty) ja näin ollen sotkee niiden todellisen kirjoitusjärjestyksen ja antaa käyttöjärjestelmälle väärän kuvan siitä, mitä levylle on tallennettu ja mitä ei ole.
Kuten tiedämme. mm. SD-korteilla on samaa taipumusta, eli tiedot sekoaa, jos kaikki ei toimi optimisti. En nyt kaivanut mitän yksittäistä tukimusta sille, mutta...
-
Anyway, tässä vielä linkkiä faktaan, ettei vaan huulet heilu. Suosittelen tutustumaan, asiallista settiä ja huolella tehty.
Understanding the Robustness of SSDs under Power Fault (https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf)
Tuli itseasiassa luettua tuo läpi ja kaikki vaikutti ihan normaalilta kunnes tuli vastaan tuo virtalähdetoteutus. Eihän tuo ole millään lailla realistinen tapa katkaista virtaa järjestelmästä. Eli lähetetään jatkuva datastreami asemalle ja erillisellä piirillä katkaistaan lennosta virta, niin että järjestelmä yrittää kuitenkin tuupata tuota streamia koneelle? En kyllä luottaisi tuollaisiin tuloksiin henk.kohtaisesti pätkääkään.
Jo tämä todistaa sen.
This separation of power supplies enables us to test the target device intensively without jeopardizing other circuits in the host systems.
Vielä pahempi. Jos oikein käsitin, niin eikö noille asemille kytketty taas satunnaisesti virta takaisin ja huom. tilanteessa jossa väylään yritettiin tallentaa kokoajan? Siis mitä ihmettä? Kelle on tullut pieneen mieleenkään tehdä noin epärealistinen testi. Joo-o tottahan toki CPU ja väylät jää aina sähkökatkoksissa henkiin, eikä konkat voi myökään normaalijärjestelmässä kompensoida yhtään tuota tilannetta. Ei hyvää päivää ;D
Onkohan nuo poloiset vielä kytkeneet asemat eri virtalähteeseen ja erivaiheen kautta. Selittäisi ainakin hyvin täysin brikkautuvat laitteet. Jotenkin tuon koekytkentälevyn kuvan perusteella en ihmettelisi asiaa :)
-
Tuossa juuri lueskelin yhtä data foorumia, ja ne sanoi että ext4:n suurimpia ongelmia on 'bit rot' ja 'silent error'. Kuten todettu, ext4 ei tee mitään sen eteen, että data ei olisi korruptoitunutta. Jos levyn firmis ei takaa tuota jollain tavalla, niin tiedostojärjestelmä ei havaitse korruptoitumista.
https://en.wikipedia.org/wiki/Bit_rot
https://en.wikipedia.org/wiki/Data_corruption
Tuo bit rot on todella petollinen, koska se voi tapahtua vuosien mittaan ja jos todellakin backupit otetaan aina "päälle" tai ei pidetä vuosien mittaista historiaa jossa data on tuoretta, niin voi johtaa tilanteeseen jossa backupit on myös täysin pilalla.
-
Kaksi asiaa tuli mieleen tässä.
1. Automaatinnen chekkaus on muuten todella nihkeää välillä, eli varsin ei toivottavaa. Journalin idea on juuri siinä, että koko järjestelmää ei tarvitse chekata. Jos iso levyjärjestelmä chekataan, se voi kestää useita tunteja tai jopa vuorokausia, eikä se ole aina kovin toivottavaa varsinkin jos se ilmenee random crashin jälkeen.
2. Tuli muuuten eilen illalla aika tyylikäs yhdestä SSD levystä: http://aijaa.com/nKsdFt (2 kuvaa)
-
Sattumalta vielä Arstechnica sattui myös kirjoittamaan artikkelin ihan tuoreeltaan samasta aiheesta:
http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/
Hyvää tekstiä ja paljon asiaa.