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

[andylove]

Kjører alltid en clean install av Win7. Denne gangen delte jeg disken i 2 partisjoner før jeg installerte. Win7 lagde allikevel 100MB partisjon for systemfiler. Riktignok hadde jeg ikke aktivert den andre partisjonen før jeg var ferdig med alle programvare installasjoner. (hadde glemt den... hehe).

 

Men hva er problematisk med at Win7 lager en slik partisjon som er synlig under installasjon og i diskmanager, men ikke i OS'et? 100MB tror jeg de aller fleste kan avse..

 

Skjønte det var et issue med flere disker og at dette kunne stå noe i veien, men det har jeg aldri vært borti før.

Endret 9. januar 2010 av andylove

[Anv]

Jeg laget en liten video av et batch script som Ourasi har satt sammen i SSD Benchmark tråden.

 

Batchfila er kjørt på et Gigabyte UD6, Ci7 860 uklokket og en Kingston V 40GB.

 

batch.mpg

 

Ta dere en tur til benchmark tråden for videre diskusjon om batch filer.

(link finner dere i min signatur)

[GlennLimos]

Jeg har ikke giddi å lest ALT som står her inne, men jeg får en viss ide om hva jeg ønsker å ha i en eventuell PC jeg kjøper i nærmære fremtid. Det jeg lurer på når det kommer til SSD er hvor alvorlig er dette ytelsestapet som kommer etter lengre tids bruk? Jeg ønsker topp ytelse og vurderer SSD til OS (og muligens enkelte andre programmer) og kjøre to velociraptor i RAID 0 når det kommer til spill. Eller vil jeg tjene på å ha OS sammen med velociraptoren?

 

Takker for alle svar

[anordne]

Så lenge ssd støtter TRIM og man ikke stapper disken helt full, ha 20%-30% ledig til enhver tid er det ikke ytelsetap. En intel gen 2 er raskere som systemdisk enn to vraptorer i raid.

[GullLars]

Som anordne sier, Intel x25-M 80GB med TRIM firmware slår 2x velociraptor i RAID-0 som system- og program-disk. Spill derimot vil tjene lite på å være på SSDen over velociraptor RAID siden det er mye båndbredde-begrenset, og 2x velociraptor har ganske grei IOPS i forhold til hva de fleste spill krever.

 

20-30% ledig vil være en overdrivelse, men om du ønsker å ha 100% skriveytelse hele tiden må du ha omtrent noe sånt. Om du nøyer deg med 90-95% av "ut av boksen" skriveytelse burde 10-15% ledig plass holde, siden den allerede har satt av 7% når du får den.

Om du skal kjøre velociraptorene i RAID fra hovedkortet og også koble SSDen til samme kontroller vil du ikke få TRIM pga RAID mode. Du kan da partisjonere 80GB enheten til f.eks. 65-70GB i stedet for å øke den ledige plassen den har til å stokke om filer og gi et større område med fri plass den kan skrive til i "bursts", du vil da merke minimalt med degradering.

Degradering gjelder kun skriveytelse, og hovedsaklig "random write", alså skriving av små blokker tilfeldig plassert på lagringsmediet. Leseytelse blir ikke degradert.

 

 

Det er ikke nødvendig å lese hele tråden for å skjønne hva den handler om, lest den første posten (og følg linker), og postene på den/de siste siden(e)

[Amozz]

20-30% ledig vil være en overdrivelse, men om du ønsker å ha 100% skriveytelse hele tiden må du ha omtrent noe sånt. Om du nøyer deg med 90-95% av "ut av boksen" skriveytelse burde 10-15% ledig plass holde, siden den allerede har satt av 7% når du får den.

 

Behøver man egentlig mer enn det disken leveres med av ledige spare area når man har disk/os som støtter trim? Er helt med på dette når det gjelder disker/os uten trim så klart.

[Amozz]

Som jeg har antatt tidligere i tråden tror jeg TRIM bare vil være brukt i en overgangsfase før diskene selv tar seg av garbage collection. Dette er en mye smartere løsning enn bruk av TRIM kommandoen siden denne ikke krever OS støtte.

 

Hvorfor tror du dette? GC er så klart nyttig og nødvendig uansett om man har trim støtte, men disken vil - uten TRIM - aldri vite hva som faktisk er i reelt bruk på disken eller ei, og vil derved heller ikke kunne gjøre en like god jobb med GC uten dette. At man bedrer selve GC'en erstatter på ingen måte funksjonen til TRIM.

 

Bruk av spesielle programmer for å kjøre "trim" av disken med visse mellomrom derimot er helt klart en overgangsfase frem til "alle" har OS med trimstøtte.

 

Men klart, ting utvikler seg hele tiden, og før eller siden vil nok ATA med TRIM også bli erstattet, men da har jeg større tro på at det blir fordi man går over til OSD disker der disken vet enda mer om hva som reelt er i bruk eller ei enn de er i dag med TRIM.

[Anders Jensen]

Som jeg har antatt tidligere i tråden tror jeg TRIM bare vil være brukt i en overgangsfase før diskene selv tar seg av garbage collection. Dette er en mye smartere løsning enn bruk av TRIM kommandoen siden denne ikke krever OS støtte.

 

De første bevisene på min teori er allerede begynt å vise seg i markedet, den nye Marvell controlleren med 6Gbps SATA leder ann:

The write placement algorithms are similar in nature to what Intel does. There's no funny SandForce-like technology at work here. Every time a write is performed the controller does a little bit of cleanup to ensure that the drive doesn't get into an unreasonably slow performance state. Unlike Intel however, Micron does do garbage collection while the drive is idle. The idle garbage collection works independently of OS or file system.

 

TRIM is supported but only under Windows 7. There are no software tools to manually TRIM the drive. Micron hopes that its write placement algorithms and idle garbage collection will be enough to keep drive performance high regardless of OS.

<a href="http://anandtech.com/tradeshows/showdoc.aspx?i=3712" target="_blank" rel="nofollow">http://anandtech.com/tradeshows/showdoc.aspx?i=3712

</a>

Der tror jeg du tar delvis feil. TRIM er ikke noe kjapt krimskrams som er rotet sammen for å kompensere for litt sløve SSD kontrollere. TRIM løser det grunnlegende problemet med at lagringsmedier tradisjonelt ikke får beskjed fra OS om at noe slettes. Grunnen til at denne funksjonen er utviklet er i hovedsak for å kunne gjøre thin-provisioning. Men det er mange andre fordeler en kan dra også. Raskere rebuild av RAID f.eks. For SSD har TRIM også vist seg nyttig fordi sletting, og overskriving fordi det krever sletting, er så tidkrevende at en gjerne vil gjøre det når systemet er under lav last og ikke når en skal overskrive.

 

Når det gjelder manuell TRIM så er jeg enig i at det er rimelig dustete. Ideelt sett skal en manuell TRIM ikke gjøre noe som helst med disken fordi OS skal ha gjort det automatisk allerede. Det en eventuelt kunne gjort manuelt er å kjøre en delvis defragmentering med alignment på samme størrelse som pages for gjeldende SSD. Dermed får en lettere frigjort et maksimalt antall pages som så kan slettes på mediet med TRIM og GC burde bli noe mer effektivt også.

Endret 10. januar 2010 av Anders Jensen

[GullLars]

Jeg har selv tenkt på løsninger ala OSD de gangene jeg har tenkt på hvordan man kan og kanskje bør lage SSDer i årene som kommer.

Jeg vet en del protesterer mot eller har motforestillinger mot å flytte mer prosessorkraft til lagringsmediet eller nære det, men jeg tror vi vil ende opp med en betydelig del regnekraft i alle fall for høy-ytelse lagring.

 

{Advarsel: dag/natt drømming}

I tankene mine har jeg forestilt meg et par ekstra DIMM slots på hovedkortet, kanskje med PCIe 3.0 buss, for bruk til SSD. Det ville vært hyggelig å se "smarte" DIMMs med NAND flash, en kontroller, og muligens intern cache for kontrolleren. For en slik løsning kan man f.eks. implementere forskjellige modeller for forskjellige formål, og tilhørende buss bredde/klokk.

 

XLC (2-n bits pr celle, normalt 3-n) med kanskje i område 1000-5000 skrivesykler og page størrelse 64-256KB beregnet for lagring av store objekter og høy båndbredde. Om vi ser kanskje 3-5 år frem i tid (kanskje nærmere 5...) kan det være realistisk med 4bpc (bits pr cell) NAND med 1000 skrivesykler og 64/128GiB pr chip. Med pages på f.eks. 64KB og erase blocks på 1MB, og for å gjøre det litt interresant si en intern 2-4MB SRAM/DRAM buffer for å minimere write latency, gjøre intern kopiering/GC lettere, og tillate samtidig les/skriv/slett fra alle interne LUNs. Et spekulativt båndbredde tall for et slikt oppsett kanskje 100MB/s les og 40-50MB/s skriv. Som en referanse, dagens MLC klarer ca 40MB/s les og 20-25MB/s skriv (30GB vertex med 4 chips).

 

På en SO-DIMM med 16 slike chips, 4 dobbel-stacked på hver side, kan man da få et aggregat av 1-2TiB rå kapasitet, 1600MB/s les og 640-800 MB/s skriv.

Om vi forutsetter ikke så mye høyere pris per chip enn det MLC koster i dag (under 15kr pr GB * 8GB/chip = 120kr/chip) er en mulig pris for en slik SO-DIMM ca 2000kr. Dette er da snakk om (sekvensiell/større block random) ytelse og kapasitet grovt ca lik 6-8x x25-M 160GB.

 

 

Og så en annen SO-DIMM for systemdisk med 2bpc MLC NAND. En NAND chip med samme areal som dagens 8GB chips vil om 3-5 år (nærmere 5...) forhåpentligvis være 32GB pr chip. 32*16=512GB. I stedet for ONFI type standarisert "dum" flash, så vil det være noe kjekkere med muligens litt mindre fysisk chip på 16GB, en noe større SRAM/DRAM buffer/cache for samme formål som nevnt pluss for neste punkt, si f.eks. 32MB, og en enkel liten logikk del med NCQ internt i enheten for å optimalisere for latency og tillate/gjøre nyttig flere LUNs for høyere båndbredde, samt sørge for at skriv/slett ikke blokkerer (mye) for små les forespørsler.

Si f.eks. 150MB/s seq les og 80MB/s seq skriv, med en del god høyere burst (sansynligvis lik grensesnittets båndbredde til chippen), og si 10-30.000 skrivesykluser.

Totalt på SO-DIMMen blir da 256GB kapasitet, 2400MB/s les og 1300MB/s skriv. Men i motsettning til den nevnt over vil denne ha 4KB page størrelse og levere veldig god IOPS og takket være intern buffer og NCQ i NAND IC ha lite IOPS tap ved mixed r/w. Om vi forutsetter samme accesstime som dagens MLC og ekstrapolerer x25-V's ytelse (5 kanaler) til denne saken (16 kanaler) ender vi opp med (30/5)*16=96K IOPS les og (10/5)*16=32K IOPS skriv, og som nevnt med mye høyere burst skriv. 32MB intern buffer * 16 chips = 512MB fordelt buffer.

 

Med DDR grensesnitt for NAND (eller eventuelt noe ala full duplex PCIe) er det en god sjangs for at båndbredde tall pr chip kan bli større.

[Ourasi]

http://translate.google.no/translate?js=y&...sl=fr&tl=en

 

Intel nekter Kingston V40 TRIM..........

 

Orginal Link på fransk

Endret 11. januar 2010 av Ourasi

[Amozz]

Jeg vet en del protesterer mot eller har motforestillinger mot å flytte mer prosessorkraft til lagringsmediet eller nære det, men jeg tror vi vil ende opp med en betydelig del regnekraft i alle fall for høy-ytelse lagring.

 

Joda, ser klart motforestillingen her. Men på den annen side er det vel lenge siden selv en vanlig harddisk bare var en "dum" disk? Og med OSD så vil jo selve GC'en bli mye enklere noe som jeg tror vil gjøre at prosessorkraften i disken neppe behøver å økes så veldig mye. Men dette vil potensielt kunne frigjøre mye tid i systemCPU'en, noe som vil kunne gi ett enda bedre - raskere - og mer responsivt system.

 

{Advarsel: dag/natt drømming}

I tankene mine har jeg forestilt meg et par ekstra DIMM slots på hovedkortet, kanskje med PCIe 3.0 buss, for bruk til SSD.

 

Noe ala Sun Storage Flash Modules du har i tankene? Bare så dumt at de har begrenset seg til SATA 3Gb/s...

[JKJK]

Da var nok en ssd bestilt. X-25M G2 160GB til "sjøla"

[Anders Jensen]

Takk for OSD forklaringen GullLars. Fin forklaring nedenfor for de som er ukjent med konseptet. Baserer seg stort sett på å adressere objekter heller enn blokker eller filer. Kan implementeres med noen utvidelser til SCSI:

http://developers.sun.com/solaris/articles/osd.html

Siden blokkadressene i moderne lagringsmedier likevel bli oversatt internt enten det er HDD eller SSD så er det neppe så mye sekvensiell ytelse å vinne på denne typen adressering selv om den tilsynelatende er mer direkte.

 

Det virker som et interessant konsept, men igjen skal en være forsiktig med å plassere funksjonalitet for nært lagringsmediet, særlig i større systemer. En ender bare opp med å måtte gjøre det samme flere ganger oppover i hierarkiet. Det er imidlertid ingenting ved OSD som påtvinger noe slikt. Det blir mer opp til implementeringen. I små systemer kan høy kompleksitet og spesialisering noen ganger lønne seg da en kan spare noe effekt om en gjør det riktig, da en likevel ikke har store lagringshierarkier å forholde seg til.

Endret 11. januar 2010 av Anders Jensen

[Anv]

Litt om Intels planer for 2010.

 

Link

 

-2x nano prosess.

-høyere kapasitet

-økt sekvensiell skrivehastighet

 

6Gb/s kommer ikke før 2011

 

Litt info om OCZ's Vertex 2

 

Link

 

Prisene vil være høyere enn dagens Vertex pga økte kostnader med ny kontroller.

De dropper Samsung baserte SSD'er.

De vil lansere en USB 3 basert ekstern "disk".

Endret 11. januar 2010 av Anvil

[Amozz]

Takk for OSD forklaringen GullLars. Fin forklaring nedenfor for de som er ukjent med konseptet.

 

... eller de kunne følge linken til wikipedia i innlegget der jeg nevnte OSD

 

 

Siden blokkadressene i moderne lagringsmedier likevel bli oversatt internt enten det er HDD eller SSD så er det neppe så mye sekvensiell ytelse å vinne på denne typen adressering selv om den tilsynelatende er mer direkte.

 

Nå skal jeg så klart være forsiktig med å garantere at du ikke har rett her, men jeg velger å tro at du tar feil. Siden lagringsystemet opererer med objekter istedet for blokkadresser så slipper man denne adresseoversettelsen, og siden det er samme kontroller som i dag remapper blokkadresser som vil være ansvarlig for å legge ut objektene, så vil den lettere kunne legge hele objekter sekvensielt på lagringsmediet. Dette alene bør gi noe bedret sekvensiell ytelse. En annen fordel er at lagringsmediet vet hvilke databiter som hører sammen i samme objekt, og kan sørge for å prefetche hele objektet - selv om det skulle ligge fragmentert på mediet. Også dette vil kunne være med på å øke den opplevde "sekvensielle" lesehastigheten. I tillegg vil nok GC bli mye enklere, og mindre prosessering i OS'et for håndtering av disken. Derfor mener jeg at dette bør gjøre at ytelsen i systemet normalt vil være bedre med OSD enn uten gitt ellers tilsvarende media. Jeg mener også dette spesielt vil slå positivt ut for SSD.

 

 

 

Det virker som et interessant konsept, men igjen skal en være forsiktig med å plassere funksjonalitet for nært lagringsmediet, særlig i større systemer.

 

I dagens - og ikke minst morgendagens - SSD'er er det alt mye prosessering som foregår, og utviklingen viser at det blir bare mer og mer for hver generasjon SSD som kommer. Mye av den prosesseringen som skjer på disken i dag kan erstattes, eller forenkles, på en OSD disk. Med OSD så vil dette - slik jeg oppfatter det - i tillegg kunne forenkle OS'et grensesnitt mot lagringsmediet da dette ikke lengre behøver å forholde seg til blokker, kun objekter.

 

Når det gjelder større lagringsystemer så skal jeg nok være enda mer forsiktig med å si noe skråsikkert, men om jeg ikke har oppfattet dette helt feil, så behøver ikke objektene man legger på disken være det samme som "fil" (noe det normalt vil være på en enkeltstående disk), men kan være f.eks. det filfragmentet som skal legges på denne disken i ett raidsystem, eller i ett databasesystem så kan objektet være en rad i en tabell osv...

 

Men klart, påstår på ingen måte at dette er den eneste rette løsningen for all datalagring, men kun at dette er ett interessant konsept, spesielt for SSD. Hvor godt dette vil fungere i praksis med en moderne SSD gjenstår jo å se, men jeg har i alle fall personlig stor tro på dette.

 

For interesserte kan det være greit å lese artikkelen "Linux and object storage devices" - dette er mer generelt om OSD enn spesifikt for Linux, og kan være av interesse også for brukere av andre OS.

[Anders Jensen]

Du missforstår meg Amozz. Jeg sier at blokkbasert adressering definitivt vil gi best sekvensiell ytelse, men jeg tror ikke kostnaden av å innføre OSD er vesentlig. OSD har en del andre fordeler som kan være verdt å etterstrebe. F.eks robust deling av lagringsmedier, enklere multipathing og mindre grad av ugunstige plasseringer i det fysiske mediet ved normal workload. Sekvensiell ytelse er uansett trivielt så det er ikke noe en bør legge til grunn som viktig argument for en teknologi. (kan vel nevne at jeg har klart å oppnå 1,4GB/s , stor B!, kontinuerlig semi-sekvensiell lesing over CIFS med et knippe av de tregeste enterprise diskene som er på markedet)

 

Jeg har også merket meg at prosesseringen i SSD er blitt mer komplisert med det, om jeg må si det selv, fullstendig forutsigbare resultat at det knapt finnes en SSD leverandør som ikke har bæsja på leggen med hensyn på pålitelighet. Mao har de klart å lage enheter som er totalt uaktuelle for servere.

 

For å oppsummere mine innvendinger til økt kompleksitet på device nivå:

1) Økt kompleksitet gir økt feil frekvens

2) Økt kompleksitet på for lavt nivå kan gi redusert energieffektivitet, som i det lange løp er ensbetydende med redusert ytelse. (OSD er ikke en bekymring her)

3) Mange av optimaliseringene blir mer effektive hvis de implementeres ett nivå høyere (RAID kontroller eller i OS), da en kan dra nytte av dynamikk i forbindelse med variabelt antall enheter (device).

Endret 12. januar 2010 av Anders Jensen

[AtroZ]

Er det forskjell på disse to?

 

INTEL 80GB X25M MLC SSD 2.5"/ 9.5mm gen2 SKU: SSDSA2MH080G2R5

 

INTEL 80GB X25M SATA 2.5IN 9.5MM SSD DRIVE GEN2 SKU: SSDSA2MH080G2C1

 

Begge står GEN 2 på... Hvilken av de bør jeg kjøpe?

[deaktivert443556]

R5 er retail og kommer med bl.a ramme for å feste disken i en 3,5" brønn.

[SilentNET]

Er det forskjell på disse to?

 

INTEL 80GB X25M MLC SSD 2.5"/ 9.5mm gen2 SKU: SSDSA2MH080G2R5

 

INTEL 80GB X25M SATA 2.5IN 9.5MM SSD DRIVE GEN2 SKU: SSDSA2MH080G2C1

 

Begge står GEN 2 på... Hvilken av de bør jeg kjøpe?

 

R5 betyr Retail (eske med skruer og lignende). C1 betyr bare enheten i seg selv (eller bulk om du vil).

[AtroZ]

Takk til Bradbury og SilentNET. Ser den bare koster 49 kr mer på multicom. Bare for å være helt sikker før jeg bestiller: INTEL 80GB X25M G2 er fortsatt den beste ssd til en rimelig penge som OS disk?

 

Netshop har nemlig OCZ 60 GB SSD 2,5" S-ATA II TRIM/GC på ukens tilbud til 1495. http://www.netshop.no/aspx/produkt/prdinfo...spx?plid=132738

Endret 12. januar 2010 av AtroZ