Er is een hoop verwarring rondom de TRIM-bug. Er is op verschillende sites uitleg hierover gegeven, maar toch blijft dat verhaal inclusief de Linux-blacklist telkens opduiken. Terwijl dit in 95 van de 100 gevallen waarschijnlijk niet meer een probleem zal vormen. Wellicht dat het volgende overzicht wat meer duidelijkheid oplevert.
Op het forum van Macrumors hebben een aantal forumleden reeds eerder vorige maand als één van de eersten onderzoek gedaan naar
het bestaan van de trimforce-command in de laatste developer build van Yosemite 10.10.4. Een aantal insiders zijn vervolgens gaan testen waaronder
Cindori, de maker van de welbekende
TRIM Enabler. Deze laatste werd nog volop gebruikt door velen van ons tot en met Mavericks (10.9), maar na de kext-signing problematiek die Yosemite (10.10) met zich meebracht hing er een risico aan het gebruik van het programmaatje van Cindori. Kort gezegd moest je
kext-signing uit zetten om van TRIM gebruik te kunnen maken in Yosemite, met alle beveiligingsproblemen van dien.
Op een gegeven moment is de trimforce-command ontdekt in de laatste developer build door een Macrumors-forumlid, en na wat experimenteren gaf Cindori al aan dat hij
hard aan het werk was voor een nieuwe versie van TRIM Enabler om de trimforce-command te gebruiken met één druk op de knop. Een ander forumlid, ene
Temptin, had alvast
een tooltje geschreven die je bovendien
zelf kon controleren op validiteit. Deze werkte prima, TRIM draaide bij alle testers naar behoren.
Maar al gauw werd de aandacht gelegd op de disclaimer die Apple laat zien bij het uitvoeren van de trimforce-command, en de geruchten over dat de TRIM-bug bij SSD's mogelijk problemen met data-corruptie zou kunnen opleveren. Daar geeft Temptin
in een uitgebreide post heldere uitsluitsel over. Zeker de moeite waard om hem te lezen, maar ik geef hier alvast een korte samenvatting:
- Er moet onderscheid gemaakt worden tussen queued TRIM en sequential (= non-queued) TRIM.
- De bekende TRIM-bug betreft de implementatie van queued TRIM in Linux. De veelgenoemde blacklist behoort tot deze bug.
- Echter, alle moderne besturingssystemen gebruiken sequential TRIM, waaronder Windows, Mac OS X en Linux. In Windows en Mac OS X wordt standaard gebruik gemaakt van sequential TRIM. In Linux moet je dit zelf forceren door queued TRIM uit te zetten.
- Alle moderne schijven maken gebruik van sequential TRIM.
- Heb je een moderne SSD-schijf, dan werkt TRIM in principe probleemloos op Mac OS X 10.10.4 als je de trimforce-command gebruikt om TRIM te activeren.
Er is een andere TRIM-bug in Linux dat de implementatie van sequential TRIM in Linux betreft. Dat wordt uitgelegd
in dit artikel. Maar dat geldt enkel voor oude SSD-drives met bv. een SandForce-controller in combinatie met deze verkeerde implementatie van sequential TRIM in Linux. En dat is waar de disclaimer van Apple voor dient: zodat ze zich indekken voor gebruikers die de trimforce-command gebruiken onder 10.10.4 in combinatie met een oude SSD-schijf. Dat zou mogelijk problemen met data-corruptie kunnen opleveren en daar willen ze niet aansprakelijk voor gehouden worden. Overigens schijnt er met Linux devs aan gewerkt te worden om deze bug t.a.v. sequential TRIM in Linux op te lossen.
TLDR: heb je een moderne SSD-schijf, dan kun je gerust TRIM activeren onder 10.10.4 met de trimforce-command zonder dat je hoeft te vrezen voor het genoemde tweetal TRIM-bugs in Linux. De bug ten aanzien van queued TRIM is niet aan de orde, omdat Mac OS X gebruik maakt van sequential TRIM. Er is echter ook een bug ten aanzien van sequential TRIM, maar ook deze is niet van toepassing mits je een moderne SSD-schijf hebt.
[Reactie gewijzigd door Sky Lynx op 24 juli 2024 13:05]