Guide: Slik fungerer en SSD - Del 1

[Stigma]

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

[Stigma]

Er det noen mulighet for trim når en har to disker i RAID?

 

Jeg har to Intel X25-M fra 2009 som står i raid 0 (kun striping). De er merkbart tregere nå..

 

leste et sted at trim ikke funket på ssd i raid. er det noe håp for disse diskene annet enn formatering?

 

Så langt jeg vet finnes det ingen workaround for trim til RAID (enda ihvertfall).

 

Den eneste redningen må være dersom de har god garbagecollection. Har de det så er TRIM ikke absolutt nødvendig egentlig, selv om det alltid er en bonus å ha. Garbage collection alene kan holde disken rimelig oppegående av seg selv.

 

Jeg kan ikke si med sikkerhet på stående fot om din modell har garbage collection. Jeg vil tro det - men det må du nesten sjekke opp i selv.

 

-Stigma

[N o r e n g]

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

 

De fleste SSDer har nå et ekstra område som er reservert for interne operasjoner som å balansere skriving til SSDen og lignende. Intel 320-serien har for eksempel to brikker ekstra på sin nåværende 120GB-modell reservert kun for å øke levetiden.

 

Er det noen mulighet for trim når en har to disker i RAID?

 

Jeg har to Intel X25-M fra 2009 som står i raid 0 (kun striping). De er merkbart tregere nå..

 

leste et sted at trim ikke funket på ssd i raid. er det noe håp for disse diskene annet enn formatering?

 

Så langt jeg vet finnes det ingen workaround for trim til RAID (enda ihvertfall).

 

Den eneste redningen må være dersom de har god garbagecollection. Har de det så er TRIM ikke absolutt nødvendig egentlig, selv om det alltid er en bonus å ha. Garbage collection alene kan holde disken rimelig oppegående av seg selv.

 

Jeg kan ikke si med sikkerhet på stående fot om din modell har garbage collection. Jeg vil tro det - men det må du nesten sjekke opp i selv.

 

-Stigma

 

X-25M G2 har Garbage Collection, de første som kom hadde kun TRIM-støtte og ytelsen deres vil naturlig nok degradere over tid da. Eneste løsning for SSDer uten Garbage Collection er å kjøre utenfor RAID

[nipsen]

Problemet er vel at SSD´ens skrive egenskaper blir svekket over tid, hvor hdd´ens skrivearm ikke blir like lett slitt ut. Vesentlig forskjell

..mm.. vel.. i utgangspunktet snakker vi om at ssd demonstrativt har bedre ytelse på tilfeldig disk-tilgang (engelsk transliterasjon ahoy). Deretter snakker vi om et spesialtilfelle der disken alltid må skrive to ganger i stedet for en. Dette er noe som skjer med alle disker, når vi ikke får "treff" i mellomlageret, slik at "cachen" blir invalidert.

 

Så å hevde at dette er noe som gjør at ssd blir stadig tregere, det er feil. Faktisk og grunnleggende uriktig. Det er ikke tilfelle. Artikkelen hevder jo ikke at disken stadig blir seigere heller - den sier at det finnes måter å optimisere for den spesifikke ytelsesforbedringen ssd kan tilby. Og det er jo flott. Men overskriften er helt på jordet. Og den fikk meg til å trykke på linken, så whatever..

 

Uansett.. Så det neste er hvorvidt dette "spesialtilfellet" faktisk tar knekken på en ssd-disk. Eller hvor lang tid det tar før en ssd er brukt opp. Dette er en interessant diskusjon, som var veldig ivrig når de første netbookene med ssd dukket opp. Det var mange teorier den gangen, men det viser seg - om en tar en titt på faktiske lese og skrive-operasjoner - at det er store odds for at ingen vil noensinne klare å slite ut en ssd-disk laget etter ca. 2006, før den blir ødelagt eller byttet ut på noe annet vis. Dette handler om matematikk og fysikk - veldig lite rom for antagelser her. Og Hvis en blander inn at bærbare gjerne får dårlige sektorer og ytelse etterhvert takket være støt og slag, så blir hele greia rundt SSD og varighet veldig, veldig spekulativ.

 

Som jo ikke er veldig uventet når vi vet hvor "Hitler liker ssd på laptopen" artiklene kommer fra. Men nok om det..

[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.

[Stigma]

 

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.

 

så da har produsentene ved SSDer sluttet å bruke KB benevning i stedet for KiB nå?...

 

-Stigma

[Hårek]

Hva er det som er grunnen til at dataene på en SSD i det hele tatt må slettes før den kan overskrives?

Ser ut som at sletting og skriving er to forskjellige operasjoner. Det er tross alt stor forskjell på halvledere og magnetisk lagring.

"NAND flash uses tunnel injection for writing and tunnel release for erasing"

Mer info her: http://en.wikipedia.org/wiki/Flash_memory#NAND_flash

 

 

 

[BAT]

Snipp

 

så da har produsentene ved SSDer sluttet å bruke KB benevning i stedet for KiB nå?...

 

-Stigma

Corsair kaller det SSD Unformatted Capacity - Link

Samme gjelder for Crucial - Link

Intel gjør det ikke - Link

Edit:

OCZ oppgir både Raw og IDEMA kapasitet - Link

Endret 12. juni 2011 av BAT

[jonny]

Interessant artikkel, men jeg sitter igjen med et par spørsmål:

1. Hvordan holder SSD'en oversikten over hvilke pages som er ledig og i bruk? Dette må jo også lagres et sted, og endres jo kontinuerlig mens disken er i bruk? Lagres dette i RAM på SSD'en, for så å lagres permanent når strømmen forsvinner (dvs. krever batteri eller kraftige kondensatorer på SSD'en)?

2. Hva med endringer i filallokeringstabellene til filsystemet? Her er det jo typisk mye endringer, som igjen må føre til mye overskriving?

Endret 12. juni 2011 av jonny

[BAT]

Kontrolleren lagrer dette i "spare area" som den disponerer.

[jokkiz91]

For en kjempefin artikkel! Virkelig bra skrevet.

 

Er det helt umulig å aktivere TRIM for meg som har ssdnow 64 gb V series?

 

http://barrystaes.blogspot.com/2009/10/kingston-ssdnow-v-series-64gb.html

 

Etter hva jeg også leste her så ser det veldig sånn ut.

 

Er det ingenting jeg kan gjøre for å forbedre min ssd eller noen firmware å installere?

 

Setter virkelig pris på hjelp om noen kan hjelpe.

Endret 17. juli 2011 av jokkiz91

[Reeve]

 

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.

[Occi]

Finfin artikkel! Håper bare alt som er blitt nevnt her av teknikker (og andre som ikke er blitt nevnt) blir standarder på SSDer som kommer fremover, også de som ikke er high-end med sinnsyke skrive- og lesehastigheter, men kanksje noe á det vi kommer til å se i de kommende ultraportable som f. eks Asus UX21! :-)

 

Selv har jeg en Asus Eee 701 som ikke er veldig mer brukbar til enn å surfe og se på litt serier, nå som jeg har en smarttelefon, og den har en SSD (faktisk to) og de er ikke særlig raskere enn en vanlig harddisk. Morsomt å se hvor stor forskjell det egentlig er snakk om. Selv har jeg skjønt at dette ville være et problem med SSD i starten, og har holdt meg unna enda til den dag i dag. Særlig at en fil kan bli lagret veldig mange steder er ikke noe jeg er helt komfortabel med.

[ols]

Noe jeg lurer på:

 

Vil TRIM virke over hele disken hvis den er delt opp i flere partsjoner?

 

(hvis man for eksempel foretrekker XP, vil det være en ide å installere 'tiny' W7 på en liten ekstra partisjon bare for å kunne bruke Trim verktøyet?)

 

Bør man unngå de vanlige 'Wipe' funskjonene i sikkerhetsprogrammene, altså de som overskriver disken med ett-tall og nuller? Og stemmer det at man ikke skal defragmentere? (hvorfor fugte ikke slike opplysninger med disken, i så fall?)

 

 

Tilføyelse:

Da fant jeg dette fine lille verktøyet som TRIMMER partisjonen med XP, eller en hvilken som helst partisjon, fra en W7 installasjon. Når jeg velger en av partisjonene på disken og klikker på TRIM-knappen skjer ingenting det første sekundet, men deretter lyser hd-lampen jevnt et par sekunder. Så etter alt å dømme virker det som det virker.

Jeg har en ganske ny Corsair Force SSD, så noen forskjell i ytelse er forløbig ikke å vente, naturligvis. Men fremtiden blir jo straks mer fortrøstningsfull...

 

http://www.ocztechnologyforum.com/forum/showthread.php?73888-Here-s-a-tool-to-force-TRIM-your-entire-drive

Endret 13. juni 2011 av ols

[Nilsen]

For en kjempefin artikkel! Virkelig bra skrevet.

 

Er det helt umulig å aktivere TRIM for meg som har ssdnow 64 gb V series?

 

http://barrystaes.bl...eries-64gb.html

 

Etter hva jeg også leste her så ser det veldig sånn ut.

 

Er det ingenting jeg kan gjøre for å forbedre min ssd eller noen firmware å installere?

 

Setter virkelig pris på hjelp om noen kan hjelpe.

 

-melvin08

 

Den førse V- generasjonen til Kingston får du dessverre ikke gjort noe med.

 

 

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.

 

Der er det en annen variabel i bildet - SandForce. SSD-er med en kontroller fra SandForce (typisk oppgitt kapasitet i hele 10-tall, som 120 og ikke 128 GB), har en ekstra minnebrikke ombord (RAW NAND) til et slags RAID-system for å sikre seg mot at minnebrikkene kan dø. Intel har vel også begynt med noe slikt på deres nye SSD-er. Jeg skal skrive mer om det i neste del av artikkelen. En siste finpuss der gjenstår, som skal tas når jeg er tilbake fra ferie neste uke :-)

 

 

 

 

Noe jeg lurer på:

 

Vil TRIM virke over hele disken hvis den er delt opp i flere partsjoner?

 

(hvis man for eksempel foretrekker XP, vil det være en ide å installere 'tiny' W7 på en liten ekstra partisjon bare for å kunne bruke Trim verktøyet?)

 

Bør man unngå de vanlige 'Wipe' funskjonene i sikkerhetsprogrammene, altså de som overskriver disken med ett-tall og nuller? Og stemmer det at man ikke skal defragmentere? (hvorfor fugte ikke slike opplysninger med disken, i så fall?)

Mye av dette kommer også i del 2.

 

Trim vil bare virske på W7-biten, siden det er filsystemet til W7 som holder oversikten over hva som er slettet og ikke. Slik jeg har forstått det ser den ikke hva Win XP holder på med.

 

 

Med moderne SSD-er trenger du ikke wipe, og defragmentering gjør SSD-en helt av seg selv når det er behov. De er temmelig smarte :-)

 

 

[Nagel]

Flott artikkel! Slike som denne gjør det verdt å titte inn om hw.no med jevne mellomrom.

[Howard B]

Hei,

 

En liten ting jeg har fundert på. Er det ikke slik at BIOSen må være i AHCI-modus og ikke IDE for at Trim funksjonen skal fungere? Eller hvordan er egentlig dette her?

 

Håper noen kan gi meg et godt svar på dette her :-)

[Sigurd26]

 

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.ocztechnology.com/res/manuals/OCZ_Vertex2_Product_sheet_6.pdf

Endret 13. juni 2011 av Sigurd26

[KaareKanin]

Ahhh... Jeg er så grundig lei av folk som ikke forstår 1024/1000 problemet, dette er matematikk jeg er sikker på at jeg lærte i 8. Klasse, at det er så mange som ikke husker dette er skremmende! Mye av det jeg skriver har sikkert vært sagt tidligere, men jeg skriver det på nytt uansett

 

Giga betyr 10^9, dette er en metrisk prefiks, akkurat som at kilo betyr 1000 eller 10^3, f.eks. kg, som betyr 1000g. Dette er den korrekte måten å bruke disse prefiksene på, og også den måten produsenter av disker gjør. Noen operativsystemer opererer også med riktig bruk, som f.eks. OSX (ble innført i snow leopard).

 

Andre derimot, som f.eks. Windows, opererer med at en kilobyte, kb, er. 1024 byte. Den samme feilen gjør de fra kb til Mb, og fra Mb til Gb. For hver gang størrelsen øker med 1000 introduseres en ny prefiks, som vil si at fra byte til gigabyte har man endret prefiks tre ganger, og hver av disse gangene vil ha den samme feilen på 1000/1024 deler inntreffe. Dette vil si at OSet vil fortelle oss at vi bare har (1000/1024)^3 ganger den faktiske kapasiteten til disken (ca 93,13 prosent).

 

Det er helt utrolig hvor mange som ikke vet dette (les en anmeldelse av en disk på komplett, så ser dere hva jeg mener). Nå er det ikke slik at man taper kapasitet på denne feilen i regnemåte, for om OSet gjør en feil når det regner ut kapasitet på disk, så gjør det samme feil når det regner ut størrelse på filer og. Når apple endret på regnemåten i OSX fikk man ikke bedre plass, for alle filene ble tilsvarende større også.

 

Så dette har ingenting å gjøre med formatering eller feil fra produsenter, det er OSet som regner feil.

 

Edit: ellers fin og informativ artikkel!

Endret 13. juni 2011 av KaareKanin

[N o r e n g]

Ahhh... Jeg er så grundig lei av folk som ikke forstår 1024/1000 problemet, dette er matematikk jeg er sikker på at jeg lærte i 8. Klasse, at det er så mange som ikke husker dette er skremmende! Mye av det jeg skriver har sikkert vært sagt tidligere, men jeg skriver det på nytt uansett

 

Giga betyr 10^9, dette er en metrisk prefiks, akkurat som at kilo betyr 1000 eller 10^3, f.eks. kg, som betyr 1000g. Dette er den korrekte måten å bruke disse prefiksene på, og også den måten produsenter av disker gjør. Noen operativsystemer opererer også med riktig bruk, som f.eks. OSX (ble innført i snow leopard).

 

Andre derimot, som f.eks. Windows, opererer med at en kilobyte, kb, er. 1024 byte. Den samme feilen gjør de fra kb til Mb, og fra Mb til Gb. For hver gang størrelsen øker med 1000 introduseres en ny prefiks, som vil si at fra byte til gigabyte har man endret prefiks tre ganger, og hver av disse gangene vil ha den samme feilen på 1000/1024 deler inntreffe. Dette vil si at OSet vil fortelle oss at vi bare har (1000/1024)^3 ganger den faktiske kapasiteten til disken (ca 93,13 prosent).

 

Det er helt utrolig hvor mange som ikke vet dette (les en anmeldelse av en disk på komplett, så ser dere hva jeg mener). Nå er det ikke slik at man taper kapasitet på denne feilen i regnemåte, for om OSet gjør en feil når det regner ut kapasitet på disk, så gjør det samme feil når det regner ut størrelse på filer og. Når apple endret på regnemåten i OSX fikk man ikke bedre plass, for alle filene ble tilsvarende større også.

 

Så dette har ingenting å gjøre med formatering eller feil fra produsenter, det er OSet som regner feil.

 

Edit: ellers fin og informativ artikkel!

 

Nå skal det sies at jeg fikk denne kunnskapen i 1. klasse VGS, og du skjønner kanskje hvor stor interessen er for å lære noe matematikk da