fstrim für Transcend TS256GMSA340 unter Linux aktiveren oder nicht?

[le0m]

Und so sehr ich Linux mag, da Windows keine derartigen Probleme hat und ich auch sonst noch von keinem anderen OS vom diesen Problemen gehört habe, halte ich Linux an der Stelle für buggy, auch wenn die oft zu stolzen Entwickler und Fanboys das nicht einsehen.

Jedes OS hat seine Tücken. Bin gerade nach 20 Jahren Windows auf Linux umgestiegen. Wobei Windows noch in der VM weiter läuft.. Die Sache mit Trim unter Linux überrascht mich doch etwas.. Ich muss aber sagen, dass ich den Umstieg bis jetzt keineswegs bereue, im Gegenteil ich bin echt begeistert!

@Piktogramm

Ubuntu 16.04 release Apr. 2016.
Mint 18 release Jun. 2016.

Dann muss ich noch 6 Monate warten

Ich frag mal den Transcend Support oder den User (Transcend_de). Möchte wirklich ungern solange auf Trim verzichten..

 

[Holt]

Unix und Linux haben mir immer besser gefallen als Windows. aber das es dort eben auch Bugs gibt, kann man nicht abstreiten und wenn so viele SSDs angeblich buggy sind, dann scheint mit das wie bei dem Autfahrer der im Radio vom Geisterfahrer auf der Autobahn hört und sich sagt: Einer? Hunderte!!

 

[Transcend_de]

Hallo Zusammen,

der TE hat mich freundlicherweise mal darauf angestubst, selbiges habe ich natürlich dann mit unseren Linux-Spezialisten gemacht.
Ich melde mich sobald ich ein Ergebnis habe.

VG Manuel

Ergänzung (13. Januar 2016)

Ich konnte meinen Technikern eine Antwort entlocken, Details hat der TE bereits erhalten, alles weitere kann er sonst im Direktkontakt klären.

Wenn ich das richtig verstanden habe, dann kann Linux Trim auch ohne das zusätzliche Kommando ganz alleine und regelt das schon mit der SSD, zumindest in den aktuellen Versionen, fstrim ist wohl noch ein Relikt aus Zeiten in denen es keine native trim Unterstützung gab.

 

[Holt]

So ganz scheint mir das nicht zu stimmen, immerhin hat Microsoft bei Win 7 nur den Online TRIM implementiert gehabt (also was bei Linux mit der Mountoption discard gemacht wird) und erst mit Win 8 dann den Offline oder Batch TRIM im Rahmen des Defragmentierdienstes als SSD Optimierung hinzugefügt, was eben dem fstrim von Linux entspricht. Auch bieten eigentlich alle SSD Toolboxen ein solches Batch TRIM für die SSDs an. Da scheint also ein Bedarf zu sein, vielleicht weil die SSDs unter bestimmten Umständen mal TRIM Befehle ignorieren oder weil es User gibt die im Zweifel die vollen Performance während der Arbeit vorziehen und dann lieber hinterher ein Batch TRIM ausführen. Schon alleine weil dabei auch Übertragungen stattfinden, kostet Online TRIM in dem Moment wo etwas gelöscht wird ja immer auch etwas Performance.

 

[highks]

Weiß man eigentlich, wie OSX das mit dem TRIM macht?
Apple ist ja ebenfalls mit TRIM sehr vorsichtig und aktiviert es nur für zertifizierte SSD - und wenn man es mit dem relativ neuen Befehl "trimforce" im terminal aktiviert, dann wird man mindestens zwei Mal eindrücklich gewarnt, dass man dies auf eigene Verantwortung tue. In Großbuchstaben. Und wirklich, es ist echt gefährlich. Sind sie sich wirklich sicher?

Ich hatte allerdings noch nie ein Problem damit und habe auch noch nie von jemandem gehört, der mit TRIM unter OSX Daten verloren hätte.

Aber schon auffällig, dass hier die unixoiden Systeme irgendwie eher Probleme zu haben scheinen. Bzw. hat etwa Microsoft das von Anfang an so perfekt gelöst, dass es bei Windows überhaupt kein Thema war?

 

[Hallo32]

@highks

Ich könnte mir vorstellen, dass die Abstraktionsebenen unter den unixoiden System zu einen höheren Testaufwand führen. (LVM, mdraid, usw.)

Bei MS kommt alles aus einer Hand und das kann hier von Vorteil sein.

 

[le0m]

Danke Transcend_de für die Infos!

So wie es aussieht reicht wohl die SSD interne "Garbage Collection" in Kombination mit der SSD internen "Spare Area" (Reserve Sektoren).

Durch "Garbage Collection" reinigt sich die SSD von selbst. Nicht so schlagartig wie durch TRIM aber angeblich hinreichend und ohne Performance Verlust. Die Funktionsweise von "Garbage Collection" sehr kurz gefasst: Überflüssige Sektoren werden in dem Moment wo sie entstehen als solche markiert und im fortlaufenden Betrieb nach und nach aussortiert.

Die Funktionsweise von "Garbage Collection" stellt allerdings nicht sicher, dass immer eine hinreichende Menge von Sektoren zum Beschreiben zur Verfügung steht. Es besteht die Befürchtung, dass dadurch Performance verloren ginge, weil vor dem Schreiben erst gelöscht werden müsse. Hier verschaffen zwei Dinge Abhilfe:

Entweder man verwendet TRIM (auf OS Level), um große Mengen an Sektoren zu befreien oder man verlässt sich auf die SSD interne „Spare Area“ (Reserve Sektoren). Die Spare Area bietet einen SSD internen Puffer-Speicher, der unter anderem dafür verwendet wird neue Writes abzufangen, wenn keine Sektoren mehr frei sind. Dadurch bleibt die Write-Performance erhalten.

Hier mehr dazu (einfach die Abschnitte mit Spare Area suchen und lesen).

Ich denke ich nehme die "--no-model-check" Option erst mal wieder raus und belasse es bei den SSD internen Vorkehrungen. Wenn die Performance nicht einbricht verzichte ich auf Trim, solange ich nicht weiß wie es dabei um meine SSD steht. In 6 Monaten ist dann auch das neue Mint fertig. Ich hoffe mal, dass die Sache mit Trim bis dahin geklärt ist. Denn von der Sache her hätte ich nichts gegen einen Batched Trim hin und wieder, trotz der SSD internen Vorkehrungen.

 

[Holt]

Nein, eine Garbage Collection kann niemals TRIM ersetzen! Beides arbeiter vielmehr immer Hand in Hand, hier findesr Du die Erklärung warum das so ist.

 

[Hallo32]

Bei größeren SSDs kann es schon funktionieren, wenn die SSD für die typischen Alltagsaufgaben genutzt wird.

Die SSD hat 256*2^30 Byte an Nand, davon stehen 256GB den Anwender direkt zur Verfügung. Somit bleiben noch ungefähr (256 * 2^30 Byte – 256 * 10^9 Byte≈) 2^34 Byte (~17,18 GB)für die interne Nutzung.

Mit den Daten aus dem Anandtech Artikel ergibt sich beim IMFT 20 nm 128 Gbit Die eine Blockgröße von 16 * 2^10 Byte * 512 = 2^23 Byte. Dieses ergibt dann mit 2^34 Byte / 2^23 Byte = 2^11 = 2048 Blöcke für die Garbage Collection.

Mit 2048 Blöcken sollte sich eine Garbage Collection für den Alltagseinsatz realisieren lassen.

 

[Transcend_de]

Weiß man eigentlich, wie OSX das mit dem TRIM macht?
Apple ist ja ebenfalls mit TRIM sehr vorsichtig und aktiviert es nur für zertifizierte SSD - und wenn man es mit dem relativ neuen Befehl "trimforce" im terminal aktiviert, dann wird man mindestens zwei Mal eindrücklich gewarnt, dass man dies auf eigene Verantwortung tue. In Großbuchstaben. Und wirklich, es ist echt gefährlich. Sind sie sich wirklich sicher?

Ich hatte allerdings noch nie ein Problem damit und habe auch noch nie von jemandem gehört, der mit TRIM unter OSX Daten verloren hätte.

Aber schon auffällig, dass hier die unixoiden Systeme irgendwie eher Probleme zu haben scheinen. Bzw. hat etwa Microsoft das von Anfang an so perfekt gelöst, dass es bei Windows überhaupt kein Thema war?

OSX bzw. Apple ist speziell,

erst wollte man Drittanbieter aus dem Nachrüstgeschäft fernhalten, ohne eigene Nachrüstungen anzubieten, man hatte das schrittweise verschärft, am Ende mussten User am Kernel rumfummeln um Trim für Drittanbieter SSDs nutzen zu können, inzwischen hat Apple das ja gelockert, deswegen auch der neue Befehl.

Aber selbstverständlich lässt es sich Apple nicht nehmen die eigenen Nutzer weiter zu gängeln und daher die vielen Warnungen.

 

[Holt]

(~17,18 GB)für die interne Nutzung.

Wovon ein Teil für Verwaltungsdaten abgeht und ein paar Blöcke sind auch immer defekt. Ohne TRIM würde ich nur maximal 480GB oder allenfalls 500GB der Kapazität nutzen, also partitionieren und dem Contoller also mehr OP gönnen, je mehr OP umso besser.

beim IMFT 20 nm 128 Gbit

Vergiss mal das 20nm, die Transcend hat mit Sicherheit das aktuelle 16nm NAND, aber auch das dürfte 128Gbit Diesize haben.

Mit 2048 Blöcken sollte sich eine Garbage Collection für den Alltagseinsatz realisieren lassen.

Gehe mal von der Hälfte aus, dann weißt Du, dass man im Extremfall nur jeweils so 8GB schnell schreiben kann, dann bricht die Performance ein, bis die Idle-GC wieder Platz geschaffen hat. Ohne TRIM sollte man den SSDs extra OP gönnen!

 

[Transcend_de]

Die MSA340 sollte noch 20 nm sein, wenn mit der TE die S/N per P/N gibt kann ich es mit Sicherheit sagen.

Für 370 und aktueller darst Du von 16 nm ausgehen @Holt
Bei "aktueller" ggf. sogar von 15 / 1Y nm

 

[Holt]

15nm, also wird in der 370 auch Toshiba NAND verbaut.

 

[Hallo32]

Wovon ein Teil für Verwaltungsdaten abgeht und ein paar Blöcke sind auch immer defekt. Ohne TRIM würde ich nur maximal 480GB oder allenfalls 500GB der Kapazität nutzen, also partitionieren und dem Contoller also mehr OP gönnen, je mehr OP umso besser.

Bei 256 GB dürften ~256 MB für den FTL notwendig sein, ein Backup vom FTL schadet nicht, das macht dann ~512 MB. Für die Controller Firmware, diversen Logs und möglichen Bad Blocks, die nicht vom Flash Hersteller ausgeblendet wurden, nehmen wir mal großzügig 1 GB.

Dann komm ich immer noch auf ~15,68 GB für die GC.

Man beachte auch, dass wir hier im SSD Forumbereich nicht unbedingt der Durchschnitt der SSD User sind. Einige Office PCs, auf die ich ab und zu einen Blick werfe, schreiben im Jahr zwischen 512 GB und 768 GB.

Wie du 480 GB - 500 GB auf eine 256 GB SSD partitionierst, musst du mir mal bei passender Gelegenheit mal erklären.

Vergiss mal das 20nm, die Transcend hat mit Sicherheit das aktuelle 16nm NAND, aber auch das dürfte 128Gbit Diesize haben.

Für 16 nm Nand fehlen mir aktuell auch glaubwürdige Quellen zu den verwendeten Zahlen.

Gehe mal von der Hälfte aus, dann weißt Du, dass man im Extremfall nur jeweils so 8GB schnell schreiben kann, dann bricht die Performance ein, bis die Idle-GC wieder Platz geschaffen hat. Ohne TRIM sollte man den SSDs extra OP gönnen!

In Abhängigkeit davon, wie aggressiv die GC ist, würde ich von mehr als 8 GB ausgehen. Aber selbst mit "nur" 8 GB dürfte die SSD bei durchschnittlicher Verwendung eine Leistung liefern, die in Ordnung ist.

Bei Transcend ist mir bis jetzt nicht aufgefallen, dass die ihre Produkte im gehoben Enthusiastenhereich platzieren möchten.

 

[Holt]

Sorry, ich hatte 512GB im Kopf, da würde ich maximal 480 bis 500GB von nutzen, bei einer 256GB entsprechend nur halb so viel.

 

[Transcend_de]

15nm, also wird in der 370 auch Toshiba NAND verbaut.

das ist nicht richtig - ich sagte aktueller hat auch 15 nm, und der ist nicht zwangsläufig von Toshiba - sorry wenn ich so nebulös bleiben muss
Aber bedenke SSD370S und SSD370 haben verschiedene Teilenummern, sind also auf dem Papier getrennte Produkte, mal davon abgesehen, daß der TE eine MSA340 hat, die war ziemlich sicher noch 20 nm Mircon, wie dem auch sei, noch habe ich die S/N nicht um es ganz sicher sagen zu können.

 

[Holt]

15nm baut nur Flash Forward, also das Joint Venture von SanDisk und Toshiba. IMFT und Hynix haben 16nm als kleinesten Prozess und Samsung verkauft meines Wissens keine größeren Menge an NAND an andere SSD Hersteller und hat außerdem auch 16nm als kleinesten Prozess für planare NANDs.

 

[Transcend_de]

Richtig was FF angeht, aber man könnte ja auch von Sandisk kaufen, ist aber an der Stelle nebensächlich.

Was Samsung angeht täuscht Du Dich zum Glück, die sind seit Jahren einer unserer größten Lieferanten, es wird sogar gemunkelt, daß wir hin und wieder mehr Flash kaufen als Apple

Abschließend, wir sind zum Glück groß genug um mit allen Tier 1 Chiplieferanten direkt verhandeln zu können und auch unterstützt zu werden.