Guide: Slik fungerer en SSD - Del 1

[Hårek]

Så hvorfor har du ikke sendt et sint brev til ram produsentene om å følge "standarden" da?

 

Ser overhodet ingen mening eller logikk i det du sier der.

[del_diablo]

Så hvorfor har du ikke sendt et sint brev til ram produsentene om å følge "standarden" da?

 

Ser overhodet ingen mening eller logikk i det du sier der.

 

Synd for deg.

 

Hvorfor er det nødvendig å "cache" den allerede slettede filen, for å så fjerne den fra cache? Det virker meget absurd, i såfall fra et litt mer praktisk perspektiv.

Hvor ligger begrensingen?

Og hvorfor kan man ikke bare direkte overskrive blokkene som er merket som "slettet"?

[Hårek]

Det er jo akkurat det teksten i artikkelen prøver å forklare.

[NgZ]

Nei. Det blir 128 033 222 656/1024³= 119,24, mot 128GB som det står på esken. Forskjellen er altså ikke pga. ekstra lagringsplass som sikkerhet og ekstra levetid for SSDen, men pga. prefiksforskjeller. Ekstra plass er utenom dette igjen, f.eks. en 128GB SSD kommer med 128 GB tilgjengelig, som er det samme som ~119,24 GiB, men den har gjerne en ekstra die som gjør at den egentlig har for eksempel 136GB, der de ekstra 8 GBene ikke er synlig, og er for å hjelpe med de nevnte problemene.

Br noen nevnte dette, tenkte jeg skulle gjøre det.

For de som lurer, er det lagringsprodusentene som har rett. K, M og G er standariserte SI-prefikser for 1000, 1 000 000 og 1 000 000 00. Noen "kloke" hodr fant i midlertid ut at det var greiere å jukse med tallene for å gjøre det "enklere", siden den minste lagringsenhetn på disken den var mulig å fylle var 8, og det ikke går opp med 1000, men med 1024. I ettertid har de "standarisert" dette, slik at de kan si at det er de som oppgir riktige verdiere. Gnome og KDE oppgir enten riktig verdi, eller lar deg velge hvilken verdi den skal bruke (linux). Usikker på hvordan OSX gjør det, men det skulle ikke overraske meg om de gjør det rett for å minske kunders forvirring når de kjøper seg ekstern harddisk, minnepenn o.l. Windows, derimot, har vondt for å rette seg eter almenne aksepterte standarder med mindre det er nødvendig for å beholde businesskundene sine. Det er jo ikke noe nytt.

 

Til de som fortsatt tenker "OMG, men jeg lærte at det var 1024B i en MB da eg var på ungdomsskolen, og det var så kult at jeg kunne "lure" alle andre med å spørre om det: Standariserte prfikser. Du kan ikke bli sur på non om du får en liter bensin når du betaler for en liter, fordi bilprodusenten din har regnet me at en liter er 1,025 liter og du dermed får færre mil per liter..

 

Ang. TRIM, har jeg lest flere artikler som sier at TRIM er tøv, og at dette er noe diksen enten skulle ordne opp i selv undrveis, eller som skulle kjøres innimllom som en god gammeldags defragmentering for å unngå for mye slitasje på disken. Noen synspunkter på dette?

[johome]

Vet ikke om det er tøv, men vet at Nizzen har kjørt RAID 0 ( du mister TRIM ved å kjøre RAID )med flere Crucial C300 SSD'er over lang tid ( tror det var bortimot 1 år ) , uten at SSD'ene mistet noe særlig ytelse.

 

Nå er jo C300 noe spesielt da , med særdeles effektiv GC....

 

Det finnes knapt SSD'er som degraderes så lite som C300.

Isåfall må man over på SLC som er i en helt annen prisklasse.

Endret 13. juni 2011 av johome

[NgZ]

Det er da bare å sette diskene i software-RAID, er det ikke det? Med mindre man har et rådyrt RAIDkort er det jo ikke noe å tjene på å ikke kjøre raidet som et rent software-oppsett. I hvert fall ikke under linux. Klart, multiboot-løsninge blir vel ikke mulig da.

[del_diablo]

Det er jo akkurat det teksten i artikkelen prøver å forklare.

 

Ikke akkurat. Den sier at filsystemet ikke kan kommunisere med driveren til disken på riktig måte.

Det blir litt for uspesifikt.

Får vel håpe at det blir dekket i neste artikkel.

[KaareKanin]

Det var da voldsomt så off topic denne tråden skulle bli da... begynner å bli veldig uinteressant dette her. Regner med at dette heller kan diskuteres i en av de VELDIG mange trådene som omhandler GiB og GB osv...

 

Trekker fort litt ut, hadde ikke vært en diskusjon på Internet hvis ikke :-p men det er også litt on topic etter som at eksempelet artikkelforfatteren brukte på side 3 var av denne typen feil og ikke et eksempel på "spare area" som påstått. De fulle 128 GB er tilgjengelig for Windows, men Windows påstår feilaktig at det bare er 119 GB

[JohndoeMAKT]

Ang. TRIM, har jeg lest flere artikler som sier at TRIM er tøv, og at dette er noe diksen enten skulle ordne opp i selv undrveis, eller som skulle kjøres innimllom som en god gammeldags defragmentering for å unngå for mye slitasje på disken. Noen synspunkter på dette?

Det er det Torvalds mener i følge lenken min et par poster bak. Hans argumenter er om jeg husker rett:

 

-Standarden definerer ikke at noe faktisk skal gjøres med dataene. Det gjør at ytelsesmønster vil være dramatisk forskjellig mellom enheter og situasjoner.

-At kommandoen ikke kan gjøres asynkront da operativsystemet må vite om disken velger å med en gang rydde.

-At ved sletting må OS kommunisere med disk i stedet for å bare oppdatere filtabell uten å fortelle disk om det.

-At trim bare gir optimaliseringshint til GC og etter hvert som at GC blir bedre vil effekten av trim falle til den er urelevant.

-At trim heller bør utføres sikkert i tidspunkter hvor redusert ytelse går bra, på samme måte som defragmentering i dag.

-At dersom du sørger for å ha mye ledig plass er det sannsynlig at GC greier å rydde perfekt uten de kostbare trim-kommandoene.

-At dersom du har en arbeidsflyt hvor du overskriver filer (databaser f.eks) vil uansett ytelsen forbli den samme fordi slike pre-allokerer i store chuncks og overskriver data i stedet for å slette.

 

For min del ser det ut som at det er to situasjoner hvor trim hjelper stort:

-Du har en liten prosentdel av disken ledig som gjør jobben vanskelig for GC og wear leveling.

-Du skriver store mengder tilfeldige data og så utfører store slett av data.

[Viewety]

Og jeg er grundig lei bedrevitere som tar en sær teknisk matematisk utregning som selfølgelig allmenn kunnskap. Det er helt riktig at svært få vet om dette, og hvorfor i alle dager skulle man det ? Vet ikke hvilken skole du har gått på, men jeg er rimelig sikker på at jeg aldri har lært dette i 8.klasse, og om jeg hadde gjort det på det tidspunktet, antakeligvis aldri husket dette (Imidlertid husker jeg 2 vers av håvamål).

 

Selvsagt så kan man vel sikkert forvente litt mer på et forum som dette, men sånn ellers, ville jeg bli svært overrasket om noen kunne dette, om da ikke vennegjengen utelukkende består av data-nerder..

 

Det han sikter til er tallsystemer, spesifikt totallsystemet. Mener også jeg lærte om det omkring 8.klasse en gang. Rundt samme tid som vi fikk undervisning i romertall.

 

Akuratt i denne posten, er det greit at forskjellen mellom kB og KiB kommer godt til syne, da det faktisk står feil i artikkelen om hvorfor kapasiteten til SSD disken vises som mindre enn hva den er.

 

Ellers vil jeg si at artikkelen er god og interressant. Gleder meg til fortsettelsen :-)

[BAT]

Ang. TRIM, har jeg lest flere artikler som sier at TRIM er tøv, og at dette er noe diksen enten skulle ordne opp i selv undrveis, eller som skulle kjøres innimllom som en god gammeldags defragmentering for å unngå for mye slitasje på disken. Noen synspunkter på dette?

Det er det Torvalds mener i følge lenken min et par poster bak. Hans argumenter er om jeg husker rett:

 

-Standarden definerer ikke at noe faktisk skal gjøres med dataene. Det gjør at ytelsesmønster vil være dramatisk forskjellig mellom enheter og situasjoner.

-At kommandoen ikke kan gjøres asynkront da operativsystemet må vite om disken velger å med en gang rydde.

-At ved sletting må OS kommunisere med disk i stedet for å bare oppdatere filtabell uten å fortelle disk om det.

-At trim bare gir optimaliseringshint til GC og etter hvert som at GC blir bedre vil effekten av trim falle til den er urelevant.

-At trim heller bør utføres sikkert i tidspunkter hvor redusert ytelse går bra, på samme måte som defragmentering i dag.

-At dersom du sørger for å ha mye ledig plass er det sannsynlig at GC greier å rydde perfekt uten de kostbare trim-kommandoene.

-At dersom du har en arbeidsflyt hvor du overskriver filer (databaser f.eks) vil uansett ytelsen forbli den samme fordi slike pre-allokerer i store chuncks og overskriver data i stedet for å slette.

 

For min del ser det ut som at det er to situasjoner hvor trim hjelper stort:

-Du har en liten prosentdel av disken ledig som gjør jobben vanskelig for GC og wear leveling.

-Du skriver store mengder tilfeldige data og så utfører store slett av data.

Fra GullLars - SSD guruen på forumet ang trim:

TRIM hindrer at "falsk gyldig" data (data du har slettet men ikke overskrevet) blir flyttet på i wear leveling ved at maskinen sender beskjed om slettede filer til SSDen.

Garbage Collection er en form for defragmentering av freespace for å lage hele tomme blokker, og er en del av wear leveling.

TRIM gjør jobben til GC og wear leveling lettere ved å redusere overhead.

Om du er interresert i å vite mer om hvordan SSDer fungerer ligger det linker i førstepost. Se spesielt Anandtech's artikler.

 

EDIT: omformulerte meg og utdypte litt mer

 

Edit: La til litt fler gullord fra GullLars

Ytelsen kan også komme seg igjen til en viss grad uten TRIM ved idle pga. aktiv GC. Det som skjer er at fragmentene av ledig plass (data som har blitt registrert som ugyldig) blir hentet ut og satt sammen i hele blokker, og SSDen bygger opp igjen "Free Block Pool" i spare area.

 

Hvor mye ledig plass som kan hentes ut uten å forårsake mye write amplification avhenger av størrelsen på og hvor tilfeldig dataene ble gjort ugyldig. Dette avhenger av sekvensiell:random write forhold, og blokk størrelse for random writes.

 

I tillegg til å la SSDen slippe å flytte falskt gyldig data, lar TRIM også SSDen bruke denne ledige plassen som dynamisk spare area. Hvor mye man tjener på TRIM avhenger av hvor tilfeldig data skrives, og hvor mye av plassen på SSDen som er i bruk. Det er også betydelig forskjell mellom SSDer på hvor mye de tjener på TRIM.

F.eks. er C300 tilnærmet upåvirket av TRIM så lenge det ikke skrives mer enn en viss (ganske høy) % små random writes. I praksis er det bare benchmarks og intense database-aktige bruksområder som forårsaker nevneverdig degradering der. Dette gjør disse gode kandidater for RAID

Endret 14. juni 2011 av BAT

[JKJK]

Jeg leste her at det å logge av windows gir GC og TRIM "tid til å jobbe".

 

Er dette virkelig nødvendig? Jeg har mine SSD'er (Vertex 3 max iops og Intel 510) stående som single disker i logiske raid på en Areca 1880ix kontroller, noe som pdd. ikke gir støtte for trim, siden Areca ikke har firmware som støtter det.

 

Det jeg egentlig lurer på er om VT3Maxiops og Intel 510 har god nok GC til at det bare er å logge av når man drar hjem for helga.....

 

 

[BAT]

 

 

 

Jeg reagerer litt på dette:

SSD-er setter av et bestemt område for å ha nok plass til når situasjoner som dette oppstår. På bildet over har vi en SSD som fysisk har 128 GB minne innabords, men i Windows ser vi bare 119 GB. Mellomlegget, i dette tilfellet 7,1 %, er satt av til "spare area", et reservert område SSD-en bruker når den mangler et fåtall pager for å skrive dataene dine. Dette er egentlig ikke et eget fysisk område, det er dynamisk. Det viktige er at 7,1 % av blokkene spredd utover hele SSD-en er reservert og skjult for deg.

Som jeg ser på bildet har SSD-en ca. 128 milliarder byte, og forskjellen skal komme av det faktum at harddisk- og ssd-produsentene definerer 1 kilobyte som 1000 byte, og ikke 1024 byte, som OSet jobber med.

 

 

Jeg også reagerte på dette. Jeg vet ikke om spare plassen faktisk spises ut av den oppgitte plassen eller ikke, men jeg ville jo tro at SSDer hadde det samme grunnleggende problemet i forhold til benevningsforskjeller som snurredisker. Benevningene som brukes er jo ikke akkurat teknisk avhengig...

 

Det hadde vært greit å få en oppklaring på dette - for det mangler ikke nok plass i eksempelet til at det skal dekke både benevningskonverteringen og reservert plass i SSDen.

 

-Stigma

 

 

Hvis du ser på oversikten nedenfor så består en SSD av et vist antall NAND brikker. F,eks Vertex 3 har 16stk a 8GB totalt 128GB. Av disse så bruker kontrolleren ca 12,7% til som "spare area" til å drive GC og vedlikehold for å gi lengst mulig levetid og bruke minst mulig skrivesykluser på nand brikkene. Det er ikke forskjell pga 1000/1024.

Beklager, du er helt på jordet. Det er forskjellen på 1000 og 1024. Hvis du ser i tabellen din så er det ingen av tallene som stemmer med den oppgitte kapasiteten. Det er fordi kapasitetene i den tabellen åpenbart er oppgitt i GiB (1024), mens produsentene bruker GB (1000). Sånn har det vært så lenge jeg kan huske og det vil helt sikkert fortsette sånn. Den ekstra kapasiteten SSDene har er skjult for brukeren, og antageligvis også for OSet.

 

Tror du meg ikke? Se på OCZ sin informasjon om Vertex 2. De har to versjoner, 100 GB og 120 GB, som er samme SSD, begge med 128 GB kapasitet, men 100 GB-versjonen har mer ekstraplass. http://www.ocztechno...uct_sheet_6.pdf

 

 

 

 

Jeg reagerer litt på dette:

SSD-er setter av et bestemt område for å ha nok plass til når situasjoner som dette oppstår. På bildet over har vi en SSD som fysisk har 128 GB minne innabords, men i Windows ser vi bare 119 GB. Mellomlegget, i dette tilfellet 7,1 %, er satt av til "spare area", et reservert område SSD-en bruker når den mangler et fåtall pager for å skrive dataene dine. Dette er egentlig ikke et eget fysisk område, det er dynamisk. Det viktige er at 7,1 % av blokkene spredd utover hele SSD-en er reservert og skjult for deg.

Som jeg ser på bildet har SSD-en ca. 128 milliarder byte, og forskjellen skal komme av det faktum at harddisk- og ssd-produsentene definerer 1 kilobyte som 1000 byte, og ikke 1024 byte, som OSet jobber med.

 

 

Jeg også reagerte på dette. Jeg vet ikke om spare plassen faktisk spises ut av den oppgitte plassen eller ikke, men jeg ville jo tro at SSDer hadde det samme grunnleggende problemet i forhold til benevningsforskjeller som snurredisker. Benevningene som brukes er jo ikke akkurat teknisk avhengig...

 

Det hadde vært greit å få en oppklaring på dette - for det mangler ikke nok plass i eksempelet til at det skal dekke både benevningskonverteringen og reservert plass i SSDen.

 

-Stigma

 

 

Hvis du ser på oversikten nedenfor så består en SSD av et vist antall NAND brikker. F,eks Vertex 3 har 16stk a 8GB totalt 128GB. Av disse så bruker kontrolleren ca 12,7% til som "spare area" til å drive GC og vedlikehold for å gi lengst mulig levetid og bruke minst mulig skrivesykluser på nand brikkene. Det er ikke forskjell pga 1000/1024.

Sorry, men jeg tror ikke på deg. Det er forskjell pga. 1000/1024, fordi det står også at det er 128 milliarder byte. Problemet er når man forkorter dette ned med forskjellige prefikser. Dette er synlig lagringsplass. Som du ser selv i listen er det to disker som skiller seg ut, nemlig de to første. Der er kapasitet og "raw nand" kapasitet identisk, og man får ut ca. 120 milliarder byte, som blir ca. 120GB, eller ca. 111GiB. De fire siste derimot, har større "raw nand" kapasitet, enn oppført kapasitet, for eksempel Intel 320 som står med 160GB, men som har 176GB fysisk. Her er det 16 GB ekstra for sikkerhet, og det utnyttbare på disken er på 160GB, eller ca. 149 GiB.

Nå er ikke listen min men kommer direkte i fra Anandtech som det er linket til på siste side i artikkelen. Dere kan lese denne her. I samme artikkelen så kan dere selv telle antall nand på hver SSD og komme frem til de samme tallene som tabellen oppgir.

Som en av postene litt lengre bak i tråden så linket jeg til stort sett alle SSDene i fra tabellen og viser hva de oppgir.

 

Corsair kaller det SSD Unformatted Capacity - Link

Samme gjelder for Crucial - Link

Intel gjør det ikke - Link

OCZ oppgir både Raw og IDEMA kapasitet - Link

[Gjest Slettet-qfohT7]

Og jeg er grundig lei bedrevitere som tar en sær teknisk matematisk utregning som selfølgelig allmenn kunnskap. Det er helt riktig at svært få vet om dette, og hvorfor i alle dager skulle man det ? Vet ikke hvilken skole du har gått på, men jeg er rimelig sikker på at jeg aldri har lært dette i 8.klasse, og om jeg hadde gjort det på det tidspunktet, antakeligvis aldri husket dette (Imidlertid husker jeg 2 vers av håvamål).

 

Selvsagt så kan man vel sikkert forvente litt mer på et forum som dette, men sånn ellers, ville jeg bli svært overrasket om noen kunne dette, om da ikke vennegjengen utelukkende består av data-nerder..

 

Det han sikter til er tallsystemer, spesifikt totallsystemet. Mener også jeg lærte om det omkring 8.klasse en gang. Rundt samme tid som vi fikk undervisning i romertall.

 

Akuratt i denne posten, er det greit at forskjellen mellom kB og KiB kommer godt til syne, da det faktisk står feil i artikkelen om hvorfor kapasiteten til SSD disken vises som mindre enn hva den er.

 

Ellers vil jeg si at artikkelen er god og interressant. Gleder meg til fortsettelsen :-)

 

Er enig i at det hører hjemme å spesifisere dette her, siden det var noe uklart i artikkelen. Jeg kan nok også erindre at 8.klasse om mulig introduserte andre tallsystem. Det jeg imidlertid ikke var enig i er at å overføre disse tallsystemene til harddiskplass skulle være allmenn kunnskap. Ihvertfall ikke slik de fleste butikker "villeder" kundene sine. De aller fleste har vel et særdeles lite forhold til hva en GB er for noe en gang. Som fattern pleier å spørre om, "Er det plass til alle disse fem dokumentene på bare én cd?"

Endret 14. juni 2011 av Slettet-qfohT7

[maiser]

Det her med TRIM og GClean er kun "teorier"(noen vil kalle det løgn) som viser seg å funke svært minimalt. Praksis viser at f eks SSD disker med Sandforce chip blir sekvensiell skrivehastighet redusert fra ca 200 Mb i sekundet til ca 80 Mb i sekundet etter kun et par måneder med normalt bruk. Bare søk litt på google så finner dere ut dette.(OCZ og anandtech forum)

 

Jeg har sjøl erfart dette og har kommet frem til konklusjonen at en moderne SSD disk er kjapt nok, men etter en liten stund er det ikke så kjapt som det burde være i forhold til prisen en har betalt og produktbeskrivelsen.

 

Jeg føler meg rett og slett lurt av produsenten!(i mitt tilfelle Sandforce fra Coisair). Det burde stå helt klart i reklamen for lese/skrivehastighet at skrivehastigheten spesielt faller drastiskt etter relativt kort tid og gjennomsnitt lese/skrivehastighet over lengre tid burde være regelen for hva de oppgir(ikke top speed som kun er i en veldig kort stund etter secure format).

[Terrasque]

Helt horribelt med tull og svada i denne tråden...

 

Ska vi se... Først, det med sletting av filer..

 

Det som skjer i praksis når en fil blir slettet, er at filsystemet markerer det området filen er på som ubrukt. Filsystemet har en indeks som sier hvilke deler av disken hvilke filer bruker. Når en fil blir slettet, blir indeksen endret fra "Det området blir brukt av fil XXX" til "Det området er ikke i bruk" - legg merke til at dette skjer i metadata i filsystemet, ikke fysisk på disken. Faktisk er det ikke noe som heter "å slette" data fra en snurredisk.

 

I datamaskinen's barndom så nullet man ut det dataområdet (med å skrive binary 000000000000....0000 over hele området filen brukte), men det eneste det gjør er 1. å slite mer på disken (overskrive en gang når "sletter", skrive en gang til når lagre data over), og 2. gjør ting tregere (å skrive data til disk tar tid). Det er ikke noe som heter å slette på en snurredisk, eneste er å overskrive. Så filsystem holder orden på hva som er i bruk og hva som kan overskrives, og disken lagrer og henter bits.

 

Så kom SSD'ene, som er helt forskjellige på grunnleggende områder. Der er det begrenset med skriving på hver celle, og "skriving" består av å endre "0" bits til "1" bits. Eneste måten å skrive en "0" bit fra en "1" bit er å slette hele blokken (ved hjelp av høyspenning) og så endre riktige bits til "1" igjen. Å slette en blokk tar forresten tid (sett i forhold til "vanlig" skriving).

 

Sånn, nå som dere vet det, så begynner kanskje resten å bli litt mer logisk. SSD'en holder oversikt over skrevne blokker, uskrevne blokker, og hvor mange ganger blokkene er blitt slettet. Wear leveling og GC er i bunn og grunn å fordele dataene jevnt utover, og stokke om på dataene så man har flest mulige ledige blokker.

 

Når det gjelder slettede filer er det to måter SSD'en kan gjøre det på: 1. Den har logikk som forstår filsystemet og kan dra nytte av metadataene som blir skrevet. Det krever mer logikk på disken, som er dyrere, at den forstår alle relevante filsystemer (enda mer logikk), og at filsystem metadataen ikke endres...

 

Den andre måten er at OS / filsystem forteller disken hvilke deler av disken som ikke er i bruk lenger. Standarden for det kalles TRIM.

 

Og ja, forskjellen på størrelsen man ser på det bildet er GB / GiB - at en som skriver en artikkel om harddisker på en tenknisk side som dette ikke engang vet det.. Dypt skuffet.

[NgZ]

Les tabellen omigjen, så skjønner du hva han mener. Flere av diskene ha opgitt større raw capasity enn de markedsføres som. Mao er det EKSTRA plass til "unformatted capacity" på alle diskene i tabellen untatt to, og du vil kunne bruke den plasen som er oppgitt.

[maiser]

Produktbeskrivelsen på Sandforce er over 200Mb/s skrivehastighet. Etter et par måneder med vanlig bruk har du kanskje 100Mb/s. Og etterhvert kun 50-60 Mb/s. Uansett hva noen av dere sier om motvirkende funksjoner, så virker de minimalt på bedringen av ytelsen, og dermed er dette en skuffelse for sikkert de fleste som har anskaffet seg disse.

 

Derimot er lesehastigheten oppi 150+ Mb/s sjøl lenge etter secure formatering. Så det er ganske bra lesehastigheter.

Endret 14. juni 2011 av maiser

[N o r e n g]

Produktbeskrivelsen på Sandforce er over 200Mb/s skrivehastighet. Etter et par måneder med vanlig bruk har du kanskje 100Mb/s. Og etterhvert kun 50-60 Mb/s. Uansett hva noen av dere sier om motvirkende funksjoner, så virker de minimalt på bedringen av ytelsen, og dermed er dette en skuffelse for sikkert de fleste som har anskaffet seg disse.

 

Derimot er lesehastigheten oppi 150+ Mb/s sjøl lenge etter secure formatering. Så det er ganske bra lesehastigheter.

Jeg har hatt mine to Corsair Force 60GB kjørende i RAID0 i over seks måneder, ytelsen i dag er like god som den var da jeg kjøpte dem.

[Terrasque]

Produktbeskrivelsen på Sandforce er over 200Mb/s skrivehastighet. Etter et par måneder med vanlig bruk har du kanskje 100Mb/s. Og etterhvert kun 50-60 Mb/s. Uansett hva noen av dere sier om motvirkende funksjoner, så virker de minimalt på bedringen av ytelsen, og dermed er dette en skuffelse for sikkert de fleste som har anskaffet seg disse.

 

Derimot er lesehastigheten oppi 150+ Mb/s sjøl lenge etter secure formatering. Så det er ganske bra lesehastigheter.

 

Litt skeptisk til den påstanden. Spesielt siden min OCZ Vertex 2, som har stått som OS disk i over et halvt år nå (uten noen formatering), klarer rundt 200 mb/s skriving, og over 250mb/s lesing: