Intel X25M,1.95 år, RIP

Nu er det vel heller ikke et helt normalt driftssenarie du har der for din X25M?

/AJ

Drevet sad i et mirror hvor det blev ramt af 500 RRD filer, hvoraf langt de fleste opdateres med få sekunders mellemrum.

Vil det sige, at de fleste celler blev opdateret med få sekunders mellemrum?

Og hvad skal den så erstattes med, og havde du forventet mere af den? Det lyder som en lidt "unormal" drift, som Anders også nævner.

Har nemlig for nyligt købt en ordenlig stak til en hjemmestrikket SAN/NAS løsning og står over for at skulle købe 10 mere til samme...

Tror jeg skal have lavet noget yderligere overvågning på dem vi har i produktion :D

/Anders

Hvad med en ramdisk til dit senarie istedet?
Jeg ville mene den burde kunne holde længere; om end det selvfølgelig er dyrere for pladsen og der er et par mulige fejlmuligheder på sådanne man normalt ikke har med alm. diske / SSDer :)

/AJ

1.95 og kaput og så bytte til en ny på garantien, det lyder da som en fin metode - især hvis den "bare" er den ene side af et mirror.

I følge intel kan du forlænge levetiden betydeligt på x25m ved at udvide spare area (og samtidigt forøge hastigheden), dog med tab af kapasitet.

Dette er et link til en audio optagelse med tilhørende slide af et foredrag på IDF2009 af James Myers (Maneger SSD Application engineering, Intel) (Anden del af foredraget er af en gut fra Hitachi men det er vidst ikke så relevant).
Desværre er det en Windows Mediaplayer only thingy så du kan nok ikke se/høre foredraget, men jeg har nogle links til slidesne.
Windows Mediaplayer Audio/Slideshow:
"MEMS003 Enterprise Data Integrity and Increasing the Endurance of Your Solid-State Drive (SSD)": http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS003/f.htm

Relevante slides:
"Write Workload Affects Endurance": http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS003/orig_...
"Spare Area Affects Endurance": http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS003/orig_...
"Case Study: 144 GB User Capacity": http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS003/orig_...
"Case Study: 128 GB User Capacity": http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS003/orig_...

Alle slides kan evt. hentes med noget shell kode ala:
HTMLROOT = http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS003/
curl ${HTMLROOT}orig_Slide[73-98]_1.jpg -o orig_Slide#1_1.jpg

Et andet interessant og måske relevant foredrag på IDF2009 af James Myers
"MEMS002 Understanding the Performance of Solid-State Drives (SSDs) in the Enterprise": http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS002/f.htm

Alle slides:
HTMLROOT = http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS002/
curl ${HTMLROOT}orig_Slide[34-68]_1.jpg -o orig_Slide#1_1.jpg

MVH
Henrik

PHK: Har du et gæt på hvor mange TB der er blevet skrevet på drevet i de to år.
Stemmer det nogenlunde med de 5000 skrivninger af hver celle?
Det undrer mig at de 3 sektorer ikke bliver fejlmeldt af disken selv og skiftet ud med nogle af reserverne - men den har måske brugt dem allesammen?

I modsætning til harddiske, der hvis de er lavet ordenligt, ikke burde dø på grund af slid

What? Traditionelle elektromagnesiske diske dør da konstant af slid og deraf afsat varme. Af samme årsag skifter mange deres elektromagnetiske disk ud efter et år eller to, for at minimere ricici.

Så om noget er SSD'er da mere forudsigelige og vil ikke "dø" men istedet skrumpe den frie kapacitet.

Fejlen ytrer sig som unrecoverable read errors og efter overskrivning af de pågældende tre sektorer arter drevet sig igen.

Havde du multiple af sektorer aligned med erase blocks? Hvor meget fri plads havde den da den stod af? Fik du nogen Smart warnings før det skete?

What? Traditionelle elektromagnesiske diske dør da konstant af slid og deraf afsat varme.

De dør af mekanisk slid. Hvis du holder hovedet over det samme spor på en traditionel disk, så holder den i princippet evigt (hvis vi der bort fra slitage i spindellejet). Gør du det der svarer dertil på en SSD, så står du overfor en endeligt fastsat levetid. Den er meget absolut.

http://intelstudios.edgesuite.net/idf/2009/sf/aep/IDF_2009_MEMS003/orig_...

PHK, kan du berette hvad "smartctl" fortæller for attribut 225 og 233?

3 års produktgaranti på Intel X25-M, min egen døde for lidt over 2 uger siden købt 30.03.2009, så
en ny er modtaget fra forretningen via RMA fra Intel.

Hvilken del af "hvis de er lavet ordenligt" var det du ikke læste ? :-)

Jeg læste det skam godt, men synes bare det er en ret intetsigende bemærkning, når man tager i betragtning at du taler om en mekanisk dims med fjedre, lejer, servoer osv. der er følsom overfor tryk, stød og temperatur. Du synes at sætte lighedstegn imellem "lavet ordentligt" og "går ikke i stykker".

Det er jo en konstant afvejning, en X25E (100.000 skrivninger) er heller ikke "lavet ordentligt", men den er dog lavet bedre end X25M (10.000 skrivninger).

Og igen, med Smart overvågning burde du have fået et varsel, men det vil du ikke helt ud med?

PHK: Når du nu har så krævende opgave burde du måske overveje et DDRdrive istedet.

http://www.tomshardware.com/news/ddrdrive-ssd-announced-q1,2195.html

Det kører med traditionelt ram og har derfor ingen levetids begrænsninger.

Vil det sige, at de fleste celler blev opdateret med få sekunders mellemrum?

SSD'ere har wear-levelling, som gør, at selv om man logisk set skriver til den samme fil 50 gange, så bliver data fysisk skrevet i 50 forskellige celler, så hele disken bliver slidt jævnt istedet for den samme lille del.

Jeg synes dog, at det lyder underligt at disken er fejlet og er ligesom Casper Bang interesseret i at høre noget mere fra loggen.

SSD'ere har wear-levelling, som gør, at selv om man logisk set skriver til den samme fil 50 gange, så bliver data fysisk skrevet i 50 forskellige celler, så hele disken bliver slidt jævnt istedet for den samme lille del.

Men SSD'er skriver ikke i sektorer af 512 bytes men i blokke som er væsentligt større (jeg har hørt et par MB som typisk). Hvis skrivemønsteret er at skrive en sektor efterfulgt af flush, får man et kraftigt accelereret slid.

Men SSD'er skriver ikke i sektorer af 512 bytes men i blokke som er væsentligt større (jeg har hørt et par MB som typisk). Hvis skrivemønsteret er at skrive en sektor efterfulgt af flush, får man et kraftigt accelereret slid.

Det er controller specifikt, men Intel's X25MG1 skulle kunne skrive i 4KB pages, men slette i 512KB (128 pages af gangen).

Som ejer af X25MG2'ere ryster det mig lidt, hvis det er tilfældet at controlleren 1) ikke er i stand til proaktivt at minimere denne "write amplification" ved f.eks. at bruge tomme blocks og 2) relativt deterministisk kan forudsige fejl via wear-leveling loggen.

Netop derfor kunne det være interesant at høre en lidt mere detaljeret analyse (sector alignment, fri plads, smart status mv.).

Men SSD'er skriver ikke i sektorer af 512 bytes men i blokke som er væsentligt større (jeg har hørt et par MB som typisk). Hvis skrivemønsteret er at skrive en sektor efterfulgt af flush, får man et kraftigt accelereret slid.

Derfor har controlleren en cache, som sørger for, først at skrive når en side er fuld (evt af flere små filer).

Når en erase block skal overskrives læser kontrolleren de data ind, som skal bevares i den pågældende blok, sletter blokken, skriver data tilbage og begynder at skrive nye data. Selvom man sletter fx 1 MB kan man godt skrive flere gange bagefter, så selvom man har mange små skrivninger burde en SSD kunne holde til adskillige års brug.

Det lyder som om PHK's brug er "lidt unormalt"; men det undrer mig at disken er fejlet ifbm læsning. SSD'ere burde så vidt jeg har forstået fejle under skrivning (hvor de så vil begynde at bruge af reserven) og ikke læsning; men det ville være rart om PHK gad komme ud med lidt detaljer om diskens status.

Drevet sad i et mirror hvor det blev ramt af 500 RRD filer, hvoraf langt de fleste opdateres med få sekunders mellemrum.

Antag at få sekunders mellemrum betyder hvert 5. sekund i gennemsnit for 500 filer og hver skrivning medfører at en 4 KB page skal skrives. Flere filer kan næppe dele page så det er 500 pages hvert femte sekund, eller 100 per sekund. Antag desuden at der er tale om en 80 GB disk.

Det giver 100606024365/(8010241024/4) = 150 overskrivninger per år.

Med andre ord slet ikke noget der kommer i nærheden af de 10.000 som disken burde kunne klare. Disken burde ikke have problemer på nuværende tidspunkt, vi er flere ordener ved siden af. Forudsat at jeg regner korrekt, er der nogen der vil regne efter?

BALDUR.. forudsætter det ikke at disken er tom?
Hvad hvis disken er 95% fyldt med data der aldrig bliver slettet men kun læst fra. Er det så ikke kun de restende 5% der bliver slidt? Eller flytter disken også rundt på "permanent" data?

Min primære X25MG2 160 har skrevet 2765GB til disk, over 222 dage og har en enkelt re-allokeret sektor men ellers ingen loggede fejl. Utilitzation ligger typisk på omkring 75%, altså ca. 40GB fri + den indbyggede 7%/11GB spare.

Det er 12.5GB/dag, pænt under de 20GB/dag (i 5 år) som Intel lover. Igen, gad vide hvor mange tæsk PHK gav sin, men det må være flere magnityder større.

"Antag [...] hver skrivning medfører at en 4 KB page skal skrives"

Du regner forkert. Vi aner jo ikke hvor store mandens skrivninger er, men mon ikke vi snakker MB og ikke kB for hver skrivning.

Det kunne være interessant at se "smartctl -all /dev/sdX" for PHK's drev.

Min SSDSA2M160G2GC siger:

225 Host_Writes_32MiB 0x0030 200 200 000 Old_age Offline - 82307

Altså har jeg skrevet 2,6TB svarende til ialt 16 overskrvninger (hvis wear leveling fungerer perfekt).

Det står rrd filer. Sådan nogle skriver man typisk få hundrede bytes eller mindre til ad gangen. Et rimeligt gæt er derfor at skrivningen er meget små. Men det kan kun php svare præcist på.

Jeg har også en X25M - på Intel's hjemmeside kan man hente programmet SSD Toolbox (til Windows), der også kan vise SMART attributter. Her kan man dels se omfanget af host writes (som Rune nævner), men også en "media wearout indicator" værdi som starter på 100 og bevæger sig mod 0 som skrivekapaciteten bliver brugt op. Forhåbentligt tager algoritmen til beregning af sidstnævnte også højde for at visse typer skrivning (host writes) slider mere, målt per byte, end andre typer osv. Det kunne være interessant at se hvilken værdi PHK's disk har her - ideelt set burde den jo være 0 da disken jo er fejlet.

Dog vil jeg lige bemærke, at vi jo ikke ved at PHK's fejl har noget med SSD'ers begrænsede write endurance at gøre. Der kan jo også være tale om en "almindelig" dataintegritetsfejl, som også kunne ske på en ikke-SSD.

Ja det er svært at vide uden lidt mere konkret info. Det kommer jo f.eks. også an på filsystem og dets commit politikker.

Og netop Intel controllere er jo kendt for at være enormt gode til at holde write-amplification og wear-leveling nede. Så man er nok nødt til at basere beregning af NAND skrivninger på Intel's egen model (de må formodes at kende deres controller bedst), der siger:

(Writesamplificationleveling)/capacity

...eller...

(40000GB x 1.1 x 1.1) / 160GB

...som er 6050, ikke voldsomt langt fra de 10K skrivninger MLC NAND skulle kunne klare teoretisk.

Andre med X25G diske der kan berette om deres Smart statusflag?

Henrik, yep den flytter skam rundt også på allerede skrevne data for at fordele skrivningerne. Det er faktisk en af grundene til at TRIM kommandoen (en ny ATA kommando hvormed operativsystem kan informere disken om at en sektor ikke er i brug) kan forbedre ydelsen, idet disken så ved at ingen nu regner med indholdet af denne sektor, hvorfor den ikke behøver at skåne den underliggendes sektors indhold ved dynamisk wear-levelling, men blot kan tage området i brug. Heraf har du også forklaringen på de performanceproblemer der er set (primært før TRIM) efterhånden som disken blev fyldt op.

9 Power_On_Hours 0x0002 100 100 000 Old_age Always - 11489

225 Host_Writes_32MiB 0x0000 200 200 000 Old_age Offline - 189650

[code=bash]
mgrpc:~$ sudo smartctl -a /dev/sda | egrep '^\ \ 9|225|233'
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 4056
225 Load_Cycle_Count 0x0030 200 200 000 Old_age Offline - 56711
233 Unknown_Attribute 0x0032 099 099 000 Old_age Always - 0
[/code]

Det betyder vistnok at min disk er 1% slidt efter 4056 timers brug.

Troede jeg var den eneste der var ved at få noget galt i halsen af dén sætning. :-)

For min Intel X25-M SSD, Device Model: INTEL SSDSA2M160G2GC.
[code=text] 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 8433
225 Host_Writes_Count 0x0030 200 200 000 Old_age Offline - 68103
233 Media_Wearout_Indicator 0x0032 099 099 000 Old_age Always - 0
[/code]
@Morten jeg tror nu at det er 0 i den kolonne længst til højre som fortæller hvor slidt drevet er.

@PHK

Man kan sagtens lave diskdrev der i princippet holder for evigt, der er bare ikke nogen der vil betale for det."

Så du indrømmer at der ikke eksisterer harddiske som ikke bliver slidt. :-)

Så du indrømmer at der ikke eksisterer harddiske som ikke bliver slidt. :-)

Det er da i dén grad quotefucking, Lars.

PHK skriver i samme indlæg:

Vi har diskdrev der er både 30 og 40 år gamle der kører glimrende i datamuseum.dk og senest har vi startet en GIER tromle der ikke har kørt i umindelige tider.

Disse mekaniske lagerenheder er ikke slidte. Hvis de var ville de ikke virke i det setup de befinder sig i.

@Jesper
Er du lidt sensitiv, og uimodtagelig for logik?

Så du er sur over at mesteren selv har udtalt noget du ikke kan lide?

Det er da i dén grad quotefucking, Lars.

Nja det ved jeg ikke, der var åbentbart andre end mig der var ved at få kaffen galt i halsen af PHK's formulering.

Disse mekaniske lagerenheder er ikke slidte. Hvis de var ville de ikke virke i det setup de befinder sig i.

Hvilket setup er det? Bragt til live efter at have ligget på hylden i 30 år? Med fastmonterede læsehoveder uden servoer? Med en faktor > 1 mia. til forskel når det kommer til fysisk størrelsesforskel?

En moderne magnetisk disk laver konstant fejlkorregering, det ved folk der har prøvet at blive skræmt af output fra recovery programmer som f.eks. Spinrite [http://www.grc.com/sranalysis.htm].

Look, I get it, PHK ønsker at fremhæve en SSD's relativ deterministiske levetid. Men hvis vi vil sammenligne æbler og pærer på dén måde, så kunne vi lige så godt trække hulkort og runesten med ind i debatten også. :)

Når man diskuterer holdbarhed af SSD vs harddiske, forventer jeg ikke at det handler om museumsgenstande. :-) Men derimod hvad der er på markedet, og det interssante må også være hvad der forskellen indenfor det samme prislag.

Men det er ok at rokke ved den forestilling som jeg nok havde om at SSD er mere holdbart end harddisk. Men ud fra den info vi har fået fra Poul-Henning synes jeg ikke det er klart at det er pga. slitage i lager cellerne. Det kunne ligeså vel være pga. en fabrikationsfejl.

PS: I forhold til "quotefucking" så synes jeg ikke at den sætning er taget ud af en sammenhæng for derved at ændre betydning.

@Morten
Du har ret. Det er 99 som angiver slitage.
http://www.bit-tech.net/blog/2009/10/23/own-an-intel-ssd-tell-how-worn-o...

@Lars
Det håber jeg, for hvis det var "raw value" var der 0% tilbage...

Det kunne være sjovt at se en måling fra en sprit-ny X25M. Men det kunne især være sjovt at se output fra PHK's døde eksemplar. PHK, læser du med her?

PS: I forhold til "quotefucking" så synes jeg ikke at den sætning er taget ud af en sammenhæng for derved at ændre betydning.

Det er lige præcis det den er. Havde du taget hele PHK's indlæg med som quote, så kunne du ikke stille dit tåbelige spørgsmål. Sætningen ville ikke kunne få den betydning du lagde i den.

Runesten er også et genialt storage-device.

Tak fordi du får mig til at smile med 90% af dine indlæg! ;-)

God start på dagen før arbejde. :D

Runesten er også et genialt storage-device.

Ekstern runesten med USB altså...

Ekstern runesten med USB altså...

USlebet Bagside...