SSD-tråden: info om og diskusjon rundt SSD

[moab]

Ny artikkel på Anandtech

 

Link

 

Artikkelen anbefaler å ikke partisjonere opp hele SSD disken.. Dvs. f.eks. utelate 5-10% av plassen upartisjonert (og viktigst av alt ubrukt)..

 

Dvs. gjøre noe slikt:

1. Clean disk

2. Partisjonere på nytt og la f.eks. 5GB forbli ubrukt

3. Installer os..

 

Artikkelen forklarer godt hva som skjer når disken blir "proppfull"..

 

Dette er nok også grunnen til at Vertex'ene har fått dårlig hastighet (mine inkludert) etter bruk av IOMeter (det at den skriver en fil på all ledig plass på disken..). Jeg kommer nok til å gjøre dette, men ikke før jeg installerer Win7 RC når den kommer.

 

Andre har anbefalt å passe på at 20% av disken forblir ledig under bruk. Dette tror ikke jeg en god løsning, fordi jeg tror NTFS foretrekker ubrukte clustere når filer trenger mer plass (eller nye filer blir lagt til). - noe som forsåvidt er fornuftig for ikke skrive over slettede filer med en gang de er slettet. Andre grunner kan være å gi filer mulighet til å vokse i clustere nær seg selv; dvs. at filer blir "spredd litt" ved laging.

[Beef Supreme]

Har lest hele artikkelen nå, og det var ganske interessant egentlig.

 

Men det viser også egentlig at IOmeter ikke er en så god test som man i utgangspunktet skulle tro. På read vil IOmeter gi korrekte resultater og vise veldig nøyaktig ytelse, men på write derimot, spesielt på 4k random, så vil ikke ytelsen vises like godt som den er. IOmeter kjører testen sin via en fil som den selv oppretter, og da vil alle sektorer være i "used state". 4K write vil da ikke bli korrekt (altså, den vil bli korrekt i et worst case scenario, der SSDen din er/har vært full, men vil ikke vise hva du får på en ny format) og vil ikke vise hva du ofte vil få av ytelse. Når en SSD sletter en block på 512k vil det være mange plasser igjen til 4k skriving, så jeg tror faktisk at i de fleste tilfeller så vil man ha topp ytelse på 4k random write.

 

Derav resultatene jeg har gitt med IOmeter-testene mine som bare viser 0.42MB/s i 4k random write, mens crystal disk mark viser 1.6MB/s, noe jeg absolutt vil tro er mer korrekte tall. (Relativt i forhold til ytelsen jeg får av jMicron-kontrolleren på hovedkortet. En god kontroller vil garantert vise bedre og mer korrekte resultater)

 

Det er lett å tro at siden sekvensiell skriving blir redusert, så blir random write også redusert, men av hva jeg har lest på den testen på Anand og andre reviews, og av min egen erfaring og logiske tenking, så mener jeg på at jo lavere random write man får, jo mindre performance-hit vil man få på SSD ettersom når man kommer under 512k så er det særdeles ofte veldig mange ledige plasser.

 

Dette er nok også grunnen til at Vertex'ene har fått dårlig hastighet (mine inkludert) etter bruk av IOMeter (det at den skriver en fil på all ledig plass på disken..). Jeg kommer nok til å gjøre dette, men ikke før jeg installerer Win7 RC når den kommer.

 

Dette er grunnen til at MLC generellt får dårlige hastigheter. Accesstiden og måten MLC funker på gjør at det tar uansett lenger tid å fullføre alle operasjonene som må gjennomgåes når en blokk slettes og skrives til på nytt.

Endret 18. mars 2009 av Beef Supreme

[Anv]

Ny artikkel på Anandtech

 

Link

...

Andre har anbefalt å passe på at 20% av disken forblir ledig under bruk. Dette tror ikke jeg en god løsning, fordi jeg tror NTFS foretrekker ubrukte clustere når filer trenger mer plass (eller nye filer blir lagt til). - noe som forsåvidt er fornuftig for ikke skrive over slettede filer med en gang de er slettet. Andre grunner kan være å gi filer mulighet til å vokse i clustere nær seg selv; dvs. at filer blir "spredd litt" ved laging.

 

Wear-levelling, write amplification osv omgår akkurat det du skriver her. Man kan med andre ord ikke skrive direkte til en fysisk sektor slik som man kan på en HDD.

Det er hele poenget med Wear-levelling etc.

 

Om man lager en partisjon på en SSD som er mindre enn den fysisk tilgjengelige plassen er det med andre ord ikke sikkert at det "ledige" området ikke blir brukt.

 

At det anbefales å ha ~20% ledig er for å unngå at man får områder som rett og slett blir brukt opp i løpet av kort tid, noe som etterhvert kan resultere i at tilgjengelig plass blir mindre. ("disken" krymper)

 

De aller fleste SSD'er har i tillegg disponibel plass som ligger utenfor oppgitt kapasitet som brukes av kontrolleren.

 

Slik har jeg oppfattet det i alle fall.

Endret 18. mars 2009 av Anvil

[moab]

...

 

Wear-levelling, write amplification osv omgår akkurat det du skriver her. Man kan med andre ord ikke skrive direkte til en fysisk sektor slik som man kan på en HDD.

Det er hele poenget med Wear-levelling etc.

 

Om man lager en partisjon på en SSD som er mindre enn den fysisk tilgjengelige plassen er det med andre ord ikke sikkert at det "ledige" området ikke blir brukt.

 

At det anbefales å ha ~20% ledig er for å unngå at man får områder som rett og slett blir brukt opp i løpet av kort tid, noe som etterhvert kan resultere i at tilgjengelig plass blir mindre. ("disken" krymper)

...

 

Poenget er at operativsystemet skriver til fysiske sektorer.. SSD'en er tom før noen skriver til den.. Dvs. at den har pekere til ingenting.. Ber du den om å lese sektor 10000 vil den bare svare deg med en tom sektor - sikkert på rekorttid også (for den trenger ikke lese noe på disken for å svare). Og de ubrukte sektorene skal ikke bli skrevet til noen gang.

 

SSD'en har ikke noen måte å "se" at en sektor ikke er i bruk lengre; det er det filsystemet som holder orden på.. Til det mangler "delete" kommando implementert av filsystem / SSD. Klarer en å holde unna sektorer fra å bli skrevet av operativsystemet unngår en også at disse forbruker blokker -> en kommer ikke opp i situasjonen

 

Poenget er at alle blokkene på SSD'en kommer til å bli brukt. Men dersom f.eks. 20GB slåss om plassen til 32GB, er det mindre sannsynlig at nesten fulle blokker må reskrives for å skrive f.eks. 4KB. Mindre "slåssing" om plassen må til..

 

Litt på spissen formuleringer (muligens):

 

Wear leveling: passer på at alle blokker blir brukt like mye. selv om en blokk kanskje inneholder statiske data, blir denne flyttet avogtil likevel for at blokken skal få lik "wear".

 

Write Amplification: dersom en disk er "propp"-full medfører en 4KB skriving at en kanskje må skrive det mangedobbelte pga. lite tilgjengelige 4KB blokker. -> mye lavere ytelse og større wear enn skrivingen skulle tilsi

[Beef Supreme]

Write Amplification: dersom en disk er "propp"-full medfører en 4KB skriving at en kanskje må skrive det mangedobbelte pga. lite tilgjengelige 4KB blokker. -> mye lavere ytelse og større wear enn skrivingen skulle tilsi

 

Det er et problem ja, at SSDene er såpass små i GB størrelse. Men som jeg skreiv i posten min over, så vil det sannsynligvis ikke være et særlig problem om man har litt plass igjen. Hver gang en invalid block skrives til med f.eks en 4k fil, så vil hele blokken være ren etterpå og da har man plutselig 508k ledig til skriv som ikke vil føre til write amp. Nå har jo ikke jeg laga SSDene på markedet, så vet ikke nøyaktig hvordan de interne funksjonene håndterer slik skriving, men det skal lite til å fikse sånne funksjoner, og de aller flese leverandører skriver at de har algoritmer for å løse write amp, så tror hvertfall jeg har en del grunnlag for teoriene mine.

 

Edit: En ting som støtter opp om teorien min ang dårlig testing av write med IOmeter er jo at jeg konsekvent får 0.42MB/s, uansett innstillinger i BIOS (IDE, RAID, AHCI), om SSDen er full/nyformatert, om jeg har mye/lite ledig plass. Altså er det problemet at med IOmeter skriver den kun til "used" eller "invalid" blokker istedet for ledige blokker som man veldig ofte har.

Mens med CrystalDM ser jeg store forskjeller.

Endret 18. mars 2009 av Beef Supreme

[Goophy]

Hvorfor er det ingen som lager billige SSDer?

Trenger ikke mer enn 50MBps r/w i en laptop.

800 for 30GB er litt i stiveste laget om man bare vil ha støy og strøm-fordelene.

[Karamell2]

Ny artikkel på Anandtech

 

Link

 

Artikkelen anbefaler å ikke partisjonere opp hele SSD disken.. Dvs. f.eks. utelate 5-10% av plassen upartisjonert (og viktigst av alt ubrukt)..

 

Dvs. gjøre noe slikt:

1. Clean disk

2. Partisjonere på nytt og la f.eks. 5GB forbli ubrukt

3. Installer os..

 

Artikkelen forklarer godt hva som skjer når disken blir "proppfull"..

 

Dette er nok også grunnen til at Vertex'ene har fått dårlig hastighet (mine inkludert) etter bruk av IOMeter (det at den skriver en fil på all ledig plass på disken..). Jeg kommer nok til å gjøre dette, men ikke før jeg installerer Win7 RC når den kommer.

 

Andre har anbefalt å passe på at 20% av disken forblir ledig under bruk. Dette tror ikke jeg en god løsning, fordi jeg tror NTFS foretrekker ubrukte clustere når filer trenger mer plass (eller nye filer blir lagt til). - noe som forsåvidt er fornuftig for ikke skrive over slettede filer med en gang de er slettet. Andre grunner kan være å gi filer mulighet til å vokse i clustere nær seg selv; dvs. at filer blir "spredd litt" ved laging.

 

 

En mindre digresjon:

Jeg godtar ikke helt at man sier Anand anbefaler folk å partisjonere mindre størrelser på SSD generelt for å unngå lavere ytelse over tid.

I artikkelen står det: at man kan med en Intel X25-M endre på fordelingen av plass slik at det upartisjonerte området blir ca. 10 GB større, som på X25-E, og at kontrolleren da vil bruke det forstørrede området til slikt arbeid. En slik konklusjon kan man bare dra dersom man har detaljkunnskaper om kontrollerens virkemåte, eller prøver det ut selv i praksis.

Jeg kan ikke se at dette (i teksten) gjelder andre SSD enn Intel sine.

 

Å overføre dette til andre SSD'er og andre kontrollere, virker kanskje på meg som et skudd i mørket og vel så det. Men det kan jo være artig å prøve.

Da må det være en mulighet for å lese av "upartisjonert" område så man kan se at hele området benyttes til random writes, eller finnes det andre måter å sjekke på ? Bortsett fra "the hard way" :-(

[GullLars]

Den artikkelen fra AnandTech var veldig bra, faktisk en av de beste jeg har lest. Ikke bare starter den på et nivå som de aller fleste som leser denne tråden kan følge med på, den forklarer også grundig etter hvert som den går i dybden. Jeg kommer til å sette den som en link til anbefalt lesestoff.

Et kort sammendrag som jeg vil legge vekt på fra artikkelen:

ALLE SSD får en eller annen form for degradering over tid som en funksjon av filsystemets måte å behandle slettede filer. Problemet blir kort sagt at OS ikke forteller SSDen når en fil har blitt slettet, og derved blir alle skriv kommandoer re-write i stedet når SSDen har blitt fylt opp. Hvor mye degraderingen blir varierer kraftig (10-50%), men den gjelder hovedsaklig bare skriving, les forblir omtrent uforandret.

 

Det som er mest interresant er hvordan ACCESSTIME forandrer seg. Random write grafen på denne siden illustrerer veldig godt hvordan ytelsen ender opp. Konklusjonen her er at høyere kvalitets SSD med gode kontrollere fortsatt er mange ganger raskere enn Velociraptor, selv ved maks (naturlig) degradering. Billige JMicron kontrollere derimot tar en kraftig trøkk og blir tregere enn vanlige harddisker.

Husk at dette kun er skriveytelsen, random read forblir omtrent uforandret, så real-life ytelsen detter ikke så mye som den grafen viser.

 

Konklusjonen blir at frem til vi får mer intelligente filsystemer og OS som støtter bl.a. ATA-Trim kommandoen og SSDer som benytter seg av dette, så vil alle SSD oppleve en viss grad av ytelsesdegradering, men de som kjøper SSD av litt høyere kvalitet vil fortsatt ha ytelse mange ganger det av Velociraptor eller 15k sas.

 

Problemet med degradering kan løses ved bruk av ATA-Trim kommandoen, intelligent garbage collection, write attenuation og algoritmer for optimal skriveplassering, kombinert med en større RAM-buffer. (kontrolleren må klare å rydde unna blocker raskt nokk til å ta i mot ferdige sammensatte blocker fra attenuation kontrolleren foretar i RAM-bufferen)

 

I praksis kan den følte random write degraderingen for det meste løses med kun en større RAM-buffer, siden bursts av opp til RAM størrelsen med random write vil gå direkte til cache med >0,1ms. Hvor mange av oss skriver mer enn 32-128MB av tilfeldig små block data av gangen?

 

 

EDIT: @Karamell:

Han sier at han har snakket med intel om dette problemet med degradering. Hvis han har blitt anbefalt å la noe plass være upartisjonert fordi det vil bli brukt av x25-M som freespace til wear-leveling og garbage-collection, så stemmer det nokk. Problemet er at han ikke oppgir hvor han har det fra.

I teorien skal dette kunne stemme for alle SSDer som har en "intelligent" kontroller, men om det er slik det blir benyttet i praksis kan vi bare finne ut av ved gjett-og-sjekk metoden. Den raskeste og enkleste måten å gjøre dette på vil være å ta en CrystalDiskMark bench med kun 4KB random testen med lengder på 50, 100, 500, og 1000MB på en "clean" SSD, og så simulere en degradert SSD på den måten han foreslår, og gjennta samme test.

Deretter gjør man helt likt bare at man ikke partisjonerer hele plassen, men sparer 10-20%. Hvis det blir tydelig forskjellig degradering på 4KB random, så er det sansynligvis hold i påstanden.

Endret 18. mars 2009 av GullLars

[Karamell2]

Kanskje man kan flashe SSDen med "enterprise" firmware, og så repartisjonere. Eller det beste må jo bli open-source-modda-re-writes-fast I/O-optimized uorginal firmware.

[GullLars]

Å flashe med "enterprise" firmware er ikke noen god idè, siden enterprise er SLC og mainstream er MLC, og grunnet forskjellen i arkitektur og skriveholdbarhet må disse behandles forskjellig.

Open source firmware høres morsomt ut, men jeg tror det ville blitt ustabilt, og firmware er allerede optimalisert for IOPS. (gjelder både Intel x25 og OCZ Vertex (1199))

 

EDIT: det hørtes forresten ut som noe en gamer kunne sagt om skjermkort for å mekke hjemmelaget "enterprise" skjermkort for videoredigering ol.

Endret 18. mars 2009 av GullLars

[Karamell2]

Å flashe med "enterprise" firmware er ikke noen god idè, siden enterprise er SLC og mainstream er MLC, og grunnet forskjellen i arkitektur og skriveholdbarhet må disse behandles forskjellig.

Open source firmware høres morsomt ut, men jeg tror det ville blitt ustabilt, og firmware er allerede optimalisert for IOPS. (gjelder både Intel x25 og OCZ Vertex (1199))

 

EDIT: det hørtes forresten ut som noe en gamer kunne sagt om skjermkort for å mekke hjemmelaget "enterprise" skjermkort for videoredigering ol.

 

 

 

*WHOOPS* busted...

[torfinns]

Veldig bra tråd, GullLars!

 

I hovedpost skriver du:

 

"I værste fall er det billigere med en liten 2-porters sata raid-kort enn et nytt hovedkort eller å kaste SSD'en"

 

Kan du legge inn en anbefaling på en grei kontroller i samme avsnitt og/eller i avsnitt SSD Raid?

 

takker, torfinn

Endret 18. mars 2009 av torfinns

[Sam_Oslo]

Man kan alltid bruke "Shrink Volume" i "Disk Mangement" for å sette av 5GB også. Eller må dette bli gjort helt fra starten av på en blank disk?

Endret 18. mars 2009 av Sam_Oslo

[Beef Supreme]

@GullLars. Leste du posten jeg skreiv her ista i forhold til write-testing med IOmeter? Du vet litt mer om IOmeter enn meg, så hadde vært fint om du kunne kommentere på det.

[csharp]

Hallo!

 

Dette var en interessant tråd, men den er blitt veldig lang og jeg har nå brukt laaang tid på å lese gjennom de første 27 sidene og orker ikke lese lengre nå for å finne ut hva som er best for meg..håper noen som har fulgt tråden hele veien kan komme med en anbefaling:

 

Jeg skal ha en SSD disk i en MacBook Pro laptop. Den bør helst være 80 GB eller mer, men kan kanskje klare meg med 60 dersom det skulle være mye bedre disker i den størrelsen.

 

Prisen jeg ser for meg er selvsagt minst mulig, helst ikke mer enn 2000 kr, selv om jeg også vil vurdere alt opp til Intels 80 GB disk til 3300 kr....

 

Tenkte først på G.Skill Titan, men så leste jeg et eller annet sted at den blir altfor varm til å ha i en laptop...synes det høres rart ut, men jeg vet jo ikke.

 

Noen anbefalinger her?

[Anv]

Tenkte først på G.Skill Titan, men så leste jeg et eller annet sted at den blir altfor varm til å ha i en laptop...synes det høres rart ut, men jeg vet jo ikke.

 

Noen anbefalinger her?

 

Titan blir varm pga kontrollerne i den.

 

Den kaldeste jeg har prøvd er Intel's X25 serie.

Vertex er litt varmere men ikke varm.

[Beef Supreme]

Jeg har et par reviews i tråden du kan se i signaturen min. Er en del brukererfaringer der.

Hvis du vil ha SLC med god plass så er Mtron MOBI 64GB veldig fin (Intel også, men da må du ut med 7 høvdinger). MLC så er det Intel som er best. Disse to ligger veldig likt i pris (kommer litt ann på om du kjøper i norge eller fra utlandet) men Intel har bedre ytelse enn Mtron. Hvis du må ha SLC så er det Mtron, Hvis du vil ha MLC så er det Intel. (eller OCZ Vertex, men Intel eier den lett)

[csharp]

Ok takk for svar!

 

Vet dere om Titan blir FOR varm, eller er den bare varmere enn de andre? Er den f eks varmere enn en vanlig 5400 RPM disk?

 

Lurer også på OCZ sin Apex serie, de koster jo noen hundringser mindre enn Vertex...er det noen umiddelbare advarsler mot disse?

[Agrop]

Apex og Gskill Titan er nesten samma SSD, den blir for varm for laptop

[csharp]

Oh, ok det visste jeg ikke...jeg trodde Apex og Vertex var nesten samme, bare at Vertex har cache...og Vertex blir jo ikke så varm såvidt jeg har skjønt?