Gå til innhold

Plextor inntar SSD-markedet


Anbefalte innlegg

Videoannonse
Annonse

Dette var en særdeles dårlig artikkel.

 

Videre skal enhetene bruke såkalt Wear Leveling algoritme som er utviklet av Plextor, noe som skal redusere degradering av ytelsen.

FEIL!

Wear Leveling er slitasjehåndtering. Kontrolleren lager et logisk lag med abstraksjon mellom LBA (Logic Block Adress) filsystemet ser og de fysiske blokkene på enheten, og passer på at noen fysiske blokker ikke blir skrevet til mange ganger mer enn andre blokker selv om samme LBA blir skrevet veldig mye mer enn andre. Man har 2 mye brukte typer wear leveling: Statisk og dynamisk.

 

*Statisk wear leveling er grovt sagt at alle fysiske blokker skrives sekvensielt og det derfor ikke blir noen forskjell i antall overskrivinger. Dette er lite optimalt med hensyn til Write Amplification og Garbage Collection dersom SSDen inneholder større mengder statisk informasjon som ikke overskrives eller forandres, og/eller mottar en betydelig mengde random writes på et begrenset område av LBA.

 

*Dynamisk wear leveling er kort sagt at SSDen mesteparten av tiden prøver å skrive til de ledige blokkene som er minst brukt uavhengig av hvor de er plassert og i hvilken rekkefølge. Brukt sammen med god Garbage Collection og gode algoritmer for omplassering av "statisk data" (aka cold-files) tillater denne typen wear leveling lav write amplification og betydelig redusert slitasje på SSDen. SSDen flytter da LBA som forandres skjeldent til de mest brukte/slitte blokkene med gjevne mellomrom og prioriterer skriving av ofte forandrede LBA (hot-files) til de minst slitte blokkene.

 

 

Så over til forklaring av den GROVE feilen begått i artikkelen. Wear Leveling påvirker ikke degradering av ytelse, men slitasjen av de fysiske blokkene i SSDen. Statisk vs Dynamisk wear leveling kan derimot ha et utslag på write amplification, som kan ha et utslag på skriveytelsen siden SSDen derfor skriver mer/mindre overflødig data, men det er ikke det som er omtalt her. Alle moderne SSDer har dynamisk wear leveling.

Garbage Collection, eller mangel på det, er det som hovedsaklig påvirker degraderingen av ytelse som er observert i mange SSDer. Garbage collection er kort sagt at SSDen regelmessig må frigjøre ugyldige pages fra blokker med gyldige pages for å kunne slette dem og skrive dem på nytt. God GC gjør dette effektivt og sørger for å ha en god del ferdig slettede blokker til en hver tid SSDen kan skrive til. Så lenge det finnes ledige blokker å skrive til vil SSDen kunne skrive med full hastighet. Når SSDen skriver mye data sammenhengende og bruker opp de ledige blokkene vil hastigheten GC klarer å frigjøre pages være den bestemmende faktoren for den videre skriveytelsen. Dårlig GC kan da føre til at skriveytelsen på SSDen blir kraftig degradert når det skrives mye til den, og spesielt skriving av tilfeldig plasserte blokker, siden disse er vanskeligere å frigjøre igjen etterpå.

 

TRIM kommer her inn som et veldig nyttig punkt. Dette er en kommando som forteller SSDen når blokker blir ugyldige og gir GC mer tid til å frigjøre dem eller tillater en mer effektiv frigjøring. Uten TRIM får ikke SSDen vite at blokkene blir ugyldige før de overskrives, og må derfor ta vare på mange blokker som egentlig er ugyldige.

TRIM tillater mye mer effektiv GC, høyere opprettholdt skriveytelse om det litt ledig plass på enheten, og tillater mye mindre aggressiv GC å gjøre jobben godt nokk.

For x25-M er det observert at TRIM lar SSDen opprettholde skriveytelseytelse tilsvarende NY tilstand ved normal bruk. Uten TRIM er x25-M observert å få noen få prosent degradering av skriveytelse ved normal bruk, og lav dobbel prosent degradert skriveytelse ved perioder med veldig mye skriving som så kommer seg igjen etter litt tid uten belastning.

 

For enterprise miljøer og virkelig "sustained random write" er bildet litt annet og der kommer GC og antall flash kanaler inn i bildet, og vi snakker om betydelig redusert skriveytelse for mange SSDer, men dette er ikke en situasjon forbrukere vil komme borti.

Dette er grunnen til at f.eks. STEC sine SSDer selger godt til industri og datasentre selv om de koster over hundre kroner pr GB.

Endret av GullLars
Lenke til kommentar

Jeg vurderte det en stund, men fant ut at jeg har egentlig for mye å gjøre til å love meg bort til jounalistikk eller testing. Jeg har blitt spurt av andre sider også, f.eks. ble jeg nylig spurt av Editor for Tom's Hardware om jeg ville skrive om eller teste lagringsenheter for dem. Jeg sier som jeg sa til dem, jeg føler meg ikke komfortabel med å love meg vekk til slikt, men jeg kan godt komme med input på artikler, rettlese SSD-relaterte artikler før de postes, eller bidra med forslag og tolkninger ved tester av enheter.

 

Med mengden av unødvendige feil (som heldigvis har minsket) som har blitt postet i SSD-relaterte artikler på hw.no de siste 2 årene vil jeg egentlig foreslå at journalistene her på HW kjører artiklene innom SSD-tråden(e) for feedback før de postes på hardware.

SSD-tråden for slike artikler som denne, og benche-tråden for tester. Jeg tror det vil betydelig øke kvaliteten på slike artikler. (jeg tror jeg skal poste en tråd om dette i feedback til hardware, andre som er enige er velkomne til å poste støtte)

EDIT: her er link

 

 

Som nevnt av andre over meg og jeg glemte å poste, vi vil se IOPS data :)

Det står i artikkelen at denne SSDen er Marvel basert, og les/skriv er 140/80, det betyr denne enheten muligens kan være en JMicron basert enhet (de produseres av marvel).

Endret av GullLars
Lenke til kommentar

Jeg har en snikende følelse av at dette er er samtalen mellom plextor management, tech og markedsføring:

 

"We need to rise our empire again! No one uses cdwriters anymore! And our PVR boxes was awesome, but we where to stupid to acknowledge it! What's hot in todays market?"

 

"SSD sir, it's a new kind of "hard drive".

 

"SSD's you say? HM. Never heard of it. Buy someone cheap and sell them expensive. Let's just buy ourselves into the market. We need a piece of this! All old cd-freaks will buy them anyway. The Plex will not flex! All heil plextor!"

Lenke til kommentar

 

Wear Leveling er slitasjehåndtering. Kontrolleren lager et logisk lag med abstraksjon mellom LBA (Logic Block Adress) filsystemet ser og de fysiske blokkene på enheten, og passer på at noen fysiske blokker ikke blir skrevet til mange ganger mer enn andre blokker selv om samme LBA blir skrevet veldig mye mer enn andre. Man har 2 mye brukte typer wear leveling: Statisk og dynamisk.

 

*Statisk wear leveling er grovt sagt at alle fysiske blokker skrives sekvensielt og det derfor ikke blir noen forskjell i antall overskrivinger. Dette er lite optimalt med hensyn til Write Amplification og Garbage Collection dersom SSDen inneholder større mengder statisk informasjon som ikke overskrives eller forandres, og/eller mottar en betydelig mengde random writes på et begrenset område av LBA.

 

*Dynamisk wear leveling er kort sagt at SSDen mesteparten av tiden prøver å skrive til de ledige blokkene som er minst brukt uavhengig av hvor de er plassert og i hvilken rekkefølge. Brukt sammen med god Garbage Collection og gode algoritmer for omplassering av "statisk data" (aka cold-files) tillater denne typen wear leveling lav write amplification og betydelig redusert slitasje på SSDen. SSDen flytter da LBA som forandres skjeldent til de mest brukte/slitte blokkene med gjevne mellomrom og prioriterer skriving av ofte forandrede LBA (hot-files) til de minst slitte blokkene.

 

 

Så over til forklaring av den GROVE feilen begått i artikkelen. Wear Leveling påvirker ikke degradering av ytelse, men slitasjen av de fysiske blokkene i SSDen. Statisk vs Dynamisk wear leveling kan derimot ha et utslag på write amplification, som kan ha et utslag på skriveytelsen siden SSDen derfor skriver mer/mindre overflødig data, men det er ikke det som er omtalt her. Alle moderne SSDer har dynamisk wear leveling.

Garbage Collection, eller mangel på det, er det som hovedsaklig påvirker degraderingen av ytelse som er observert i mange SSDer. Garbage collection er kort sagt at SSDen regelmessig må frigjøre ugyldige pages fra blokker med gyldige pages for å kunne slette dem og skrive dem på nytt. God GC gjør dette effektivt og sørger for å ha en god del ferdig slettede blokker til en hver tid SSDen kan skrive til. Så lenge det finnes ledige blokker å skrive til vil SSDen kunne skrive med full hastighet. Når SSDen skriver mye data sammenhengende og bruker opp de ledige blokkene vil hastigheten GC klarer å frigjøre pages være den bestemmende faktoren for den videre skriveytelsen. Dårlig GC kan da føre til at skriveytelsen på SSDen blir kraftig degradert når det skrives mye til den, og spesielt skriving av tilfeldig plasserte blokker, siden disse er vanskeligere å frigjøre igjen etterpå.

 

TRIM kommer her inn som et veldig nyttig punkt. Dette er en kommando som forteller SSDen når blokker blir ugyldige og gir GC mer tid til å frigjøre dem eller tillater en mer effektiv frigjøring. Uten TRIM får ikke SSDen vite at blokkene blir ugyldige før de overskrives, og må derfor ta vare på mange blokker som egentlig er ugyldige.

TRIM tillater mye mer effektiv GC, høyere opprettholdt skriveytelse om det litt ledig plass på enheten, og tillater mye mindre aggressiv GC å gjøre jobben godt nokk.

For x25-M er det observert at TRIM lar SSDen opprettholde skriveytelseytelse tilsvarende NY tilstand ved normal bruk. Uten TRIM er x25-M observert å få noen få prosent degradering av skriveytelse ved normal bruk, og lav dobbel prosent degradert skriveytelse ved perioder med veldig mye skriving som så kommer seg igjen etter litt tid uten belastning.

 

For enterprise miljøer og virkelig "sustained random write" er bildet litt annet og der kommer GC og antall flash kanaler inn i bildet, og vi snakker om betydelig redusert skriveytelse for mange SSDer, men dette er ikke en situasjon forbrukere vil komme borti.

Dette er grunnen til at f.eks. STEC sine SSDer selger godt til industri og datasentre selv om de koster over hundre kroner pr GB.

Takk for en veldig bra forklaring av wear leveling, GC og TRIM :)

Du burde absolutt legge denne infoen i første posten i SSD tråden din

Lenke til kommentar

Om du sjekker SSD-tråden holder jeg på med en full oppdatering av førsteposten. Du kan finne førsteutkastet til begynnelsen her.

Jeg vurderer også å skrive om en kopi av den nye førsteposten og levere til hardware.no som en artikkel eller en miniserie av artikler. Jeg har vært i kontakt med redaktøren og han var positivt innstilt til dette.

Lenke til kommentar

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

Laster...
×
×
  • Opprett ny...