Lion, SSD och TRIM

Att SSD controllern själv håller reda på tidigare använda block som är inaktiva, och regelbundet skriver över dom i bakgrunden när disken inte används. Anandtech beskrev detta i sin Kingston V100 recension.

Kingston SSDNow V+100 Review - AnandTech :: Your Source for Hardware Analysis and News

Att SSD controllern själv håller reda på tidigare använda block som är inaktiva, och regelbundet raderar dom i bakgrunden när disken inte används.

Det är inte magnetiskt media vi pratar om. Notera att dom skriver erase och inte overwrite. Pga: du kan bara skriva 1->0 och bara radera 0->1.

Konceptuellt är det väl mer logiskt att prata om erase, istället för overwrite, men det är samma sak. Ett använt block på disken som markerats som ledigt av operativsystemet, kan skrivas över med nollor. Självklart kan man skriva nollor även till en SSD efter som all data består av en kombination av både ettor och nollor. Dessutom var ju en tidig (men obefogad) kritik mot just TRIM och liknande lösningar att de skulle slita ut disken i förtid eftersom NAND minnen har en begränsat antal möjliga skrivningar och livstid.

Måste nog insistera på att det inte är samma sak: för en Flash-disk är erase en separat funktion/kommandon/operand. Du kan bara få en bit i en Flash-cell att bli ett (1) genom radering (erase). Det går inte att skriva en etta (1) genom att skriva (write) till en cell.

Ett ledigt block raderas (vilket inte är samma sak som att skriva/write) till ett-ställt tillstånd ($FF).

Visst kan man det, men det uppnår inte dom syften som du påstår. Du får ingen radering genom att skriva nollor till en SSD.

Det är ju heller inte sant. I så fall vill jag se en referens (länk) som backar detta påstående. Du kan nämligen inte använda en SSD utan att behöva radera sectorer när du har använt upp (skrivit data) alla på hela disken. Du behöver helt enkelt börja radera (gamla) inaktiva sectorer för att kunna skriva ny eller uppdatera existerande data på disken. Men det är sant att Flash-teknologi lider av begränsad livstid. Därför har man uppfunnit sk. wear leveling. Någon form av TRIM-aktig funktionalitet måste du ha för att kunna få ut bra (=hög) prestanda. Den kan finnas i O/S:t funktion för filsystem eller i disken självt.

Du menar alltså att ett separat api krävs för att skriva till en flash disk? Man kan inte använda vanliga program som tidigare fungerat till vanliga diskar, utan man måste först skriva om det. posix system anrop som write fungerat inte längre mao?

Detta är ju intressant, du menar alltså att att det på en SSD existerar 3 tillstånd, 1, 0 och ytterligare ett. Att en etta blir en nolla, betyder inte att data försvinner mao, utan att det finns två typer av nollor?

Kan tyvärr inte göra det tänkte mest på, diskussioner på internet. Men du kanske skulle kunna bidra med en länk?

Frazze verkar ha koll på SSD...

Ja, en SSD som ansluts med t.ex. SATA har ett speciellt TRIM-kommando (särskilt API-anrop) som filsystemslagret kan utnyttja för att ange att vissa block inte längre används.

Posix-anropen är däremot likadana. Här finns lager som översätter så att du ser ett block-device, fastän det i botten inte är det.

Nej. En SSD innehåller bara nollor och ettor. Det finns två operationer (på låg nivå):
- Erase på ett block som är typ 128KB stort. Innehållet i hela blocket blir 0xFF. Detta är en relativt mycket långsam operation.
- Skriva nollor på godtycklig adress. Du kan inte skriva en etta någonstans. Detta går snabbt.

På en SSD finns en controller som mappar flashens interna egenheter till något som liknar en vanlig SATA-disk (med tillägget att det finns ett TRIM-kommando). Denna controller utför bland annat garbage collection. Denna garbage collection fungerar mycket bättre då filsystemet kan skicka TRIM-kommandot så controllern vet vilka block som filsystemet faktiskt använder.

The SSD Anthology: Understanding SSDs and New Drives from OCZ - AnandTech :: Your Source for Hardware Analysis and News
TRIM - Wikipedia, the free encyclopedia

Här är några länkar om MTD (som Lion troligen ej kommer att stödja men som kan ge ökad förståelse om hur en SSD fungerar):
http://en.wikipedia.org/wiki/Flash_Translation_Layer
http://www.linux-mtd.infradead.org/faq/general.html

Tack för insatsen, pesc!

Tror du missuppfattar vad det är jag vill ha sagt. Är det någon skillnad på write() och write(), frågan är retorisk givetvis, för att man skall se orimligheten i påståendet. Svara inte på retoriska frågor.

Nej, TRIM är inget api anrop, det är ett bara ett tillägg till standarden för ATA styr kommandon ATA8-ACS2. Frågan och min poäng var om man skall bry sig om ifall write() på en disk och write() på en SSD är olika ur diskens synpunkt. Är det någon skillnad på att skriva över en etta eller ta bort en etta (retorisk fråga).

Anledningen till att en SSD blir långsammare är att för att kunna skriva till ett block måste det vara tomt, därför måste varje skrivning till ett icke tomt block först rensas. Med trim kan controllern göra samma sak i bakgrunden.

Här är förslagen av tillägget av trim till standarden, men det kan även hittas i headerfiler på de operativ system som har trim, liksom scsi styr kommandon för usb.

http://www.t13.org/documents/UploadedDocuments/docs2010/e09158r2-Trim_Clarifications.pdf

Intel® High Performance Solid State Drive — What are the advantages of TRIM and how can I use it with my SSD?

[http://download.intel.com/design/flash/nand/mainstream/Intel_SSD_Optimizer_White_Paper.pdf

Ja det finns en skillnad.

Läser du den första artikeln jag refererade till så beskriver den hur (och anledningen till att) en SSD blir långsammare med tiden för random writes. Denna prestanda-försämring kan återställas om man gör erase på alla block på SSDn. Notera att du inte kan få samma effekt:
- Genom posix-anropet write()
- Genom att formatera om devicet i Skivverktyg
- Genom att göra en "säker radering" som skriver nollor i Skivverktyg

En SSD som har TRIM-stöd (och använder ett filsystem som stöder TRIM) kan däremot återställa prestandan (förutsatt att du inte fyllt SSDn till bredden med data).

Däremot har du rätt i att (de flesta) applikationer som använder posix read()/write() inte behöver bry sig om detta. De behöver inte skrivas om.

Men du, skillnaden ligger inte i att write() inte gör det som TRIM gör (med hänseende på att göra en etta till en nolla), utan att den logiska mappningen mellan ett block och en fil inte är 1:1 på en SSD. Anledningen till detta är att minska slitaget på disken genom att flytta block, ser controllern till att man inte skriver till samma block hela tiden. Men även detta skiljer sig mellan olika diskar, så det är omöjligt att säga något generellt.

Allt detta är ju naturligtvis dolt från user space, och även från OSét. Av denna anledningen åstakommer en write inte samma sak som om man använder TRIM, eftersom man inte vet var datan finns på disken.

Men detta är ju inta alls det som diskussionen gällde, utan om det var rätt säga "over write" istället för "erase".

Min poäng är att det är skit samma, för du 1) åstadkommer samma sak, 2) ur synvinkeln från user space, så är det ingen skillnad. Diskussionen liknar ett argument för att prata om data på diskar som analog istället för digital, eftersom från i diskens synpunkt så är den det.

Det är ingen skillnad mellan en SSD och en HD när det gäller mappningen mellan ett block och en fil. Däremot så kommer SSD:ns annorlunda uppbyggnad att påverka hur bökigt det är att modifiera en fil (jämfört med en HD).

Nej, du minskar aldrig slitaget på SSD, däremot så sprider du slitaget så att inte en och samma cell/block skrivs om och om och om och... igen. Men slitaget finns alltid där. För varje skrivning.

Så fungerar det.

Jo absolut, men som jag sa det skiljer sig mellan olika tillverkare.

http://cseweb.ucsd.edu/users/m3wei/assets/pdf/FMS-2010-Secure-Erase.pdf

Ja men det är ju det som är min poäng, genom att se till att samma cell inte skrivs till flera gånger kan controllern flytta runt filer som används mycket, vilket leder till mindre slitage av disken i helhet. Detta flyttande av filer är även anledningen till att man inte vet var exakt datan från en fil finns på disken. Se länk.

Du menar alltså att man måste ha en kontroller som förstår att det är en SSD disk man har anslutit? Det tror jag inte dom flesta SATA kontrollerkort förstår.

Jag syftade på kontrollern på disken, den gör ju att kommunikation med disken utifrån sett är identisk med en vanlig disk.

En kollega, mer än så har jag tyvärr inte just nu. Ska se om jag kan få en skärmdump på det.

Väldigt trevligt, på gränsen till värt en egen tråd. Här är lite mer info: OS X Lion Adds TRIM Support for SSDs

Är man dålig på engelska kan man läsa här på svenska: OS X Lion får stöd för TRIM - Allt om Mac

Något är inte helt 100% med TRIM ännu..

Sitter på 10.7 och en OCZ Vertex 2 120GB. Enligt System Report har den inte stöd för TRIM. Något den har i Windows 7 och enligt OCZ specs...

Du kommer väl knappast basera dina inköp på hur en betaversion av ett operativsystem hanterar TRIM?

Och hur hade du tänkt få redan på det?

Snow Leopard har också en rad med text för TRIM. Jag har en Intel SSD som har stöd för TRIM, på skärmen står det "TRIM-stöd: Nej"

Så frågan är vad "TRIM-stöd: Ja" verkligen betyder i Lion. Att filsystemet faktiskt skickar TRIM-kommandon? Eller endast att Lion noterat att SSD-enheten har en funktionalitet som heter TRIM?

Tills jag får bättre info är jag tyvärr milt skeptisk...

Ja precis. Det kan ju helt enkelt betyda att drivrutinen som apple numera använder klarar av att rapportera att hårddisken som är ansluten till hårddiskskontrollern (ATA/SATA/SAS etc) klarar av att identifera TRIM. Att operativsystemet sen gör det är ju en HELT annan sak.

Finns det något sätt att verifiera detta utan att ta fram logikanalysator som man inte har

men för vissa tredjepart-diskar som faktiskt stödjer TRIM (någon OCZ har jag för mig det gällde...?) rapporeras ändå 'nej'.
det kan ju tänkas att det är en beta-bug förståss...

Ska kolla lite på jobbet, har nyare SSD diskar där med TRIM. Får se vad lion säger där.