Recht hat er trotzdem, und da der am meisten gebrauchte "alte" Kernel wohl 2.6.32 ist, hat sein Kommentar hier sehr wohl etwas zu suchen. Kann ja niemand was dafür dass du RHEL5 nutzt (ganz zu schweigen noch im Zusammenhang mit einer SSD)
Einen Schmarren hat er recht - steht doch explizit im Artikel man möge mittels mount schauen ob relatime gesetzt ist und WENN NICHT die Option setzen
Abgesehen davon wüsste ich jetzt nichts was gegen rhel5 spricht nachdem es nun mal eine supportete LTS Distribution ist - BTW nutze ich Fedora, das ändert aber nichts daran dass ich auch über den Tellerrand sehe
"Bei SSDs von Crucial und Micron sollte man auf Trim grundsätzlich verzichten, denn Firmware-Bugs bei einigen Modellen können bei Trim und gleichzeitigen Schreibvorgängen zu Datenverlust führen."
Gibt es dazu ne Quelle? Würde gerne mehr darüber wissen, z.B. welche Modelle betroffen sind.
Der erste Link dreht sich um das sog. "queued trim", auch genannt NCQ-Trim. Das wurde mit SATA-3.1-Spezifikation eingeführt und wird mit normalen Schreib/Lese-Zugriffen quasi gleichgestellt behandelt, um den normalen Betrieb während des trims nicht zu verlangsamen. Die eine oder andere SSD-Firmware funktioniert mit Linux aber offenbar nicht sicher zusammen und es kann dann beim queued Trim zu Datenverlusten kommen. Der Kernel hält inzwischen in drivers/ata/libata-core.c eine Blacklist von SSDs vor, bei denen queued Trim (noch) nicht funktioniert und deshalb deaktiviert werden muss. Wenn man bei der aktuellen Entwicklungs des Kernels schaut, dann sind davon aber nicht nur mehrere Crucial-Serien betroffen, sondern auch Samsung 8xx-er Serien (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81). Das normale Trim scheint aber zu funktionieren, und sofern man einen Kernel und SSD zusammen benutzt bei dem queued trim nicht aktiv ist (weil nicht in der SSD vorhanden oder vom Kernel geblacklistet), hat man wohl kein Problem damit. Kernel-Versionen vor 3.12 sind gar nicht betroffen, weil es da noch kein queued trim gab, für spätere muss man auf die Version/Revision/Patches achten was geblacklistet ist, aber evtl. kann auch ein Firmwareupdate der SSD helfen (zumindest bei betroffenen SSDs; bei älteren, die queued trim noch nicht hatten, sollte man ein Update dann gerade unterlassen).
Der zweite Link dreht sich wohl um ein Problem mit der mitgelieferten Windows-Software und ist zumindest für Linux-only-User wohl nicht existent. Bitte hinzufügen, falls jemand noch weitere Datenverlust-Probleme bei SSDs kennt/findet.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 15. Mai 2015 um 12:51.
Von ssds sind scheisse am Do, 14. Mai 2015 um 21:59 #
Bei manchen SSDs gab es nen Bug wenn gerade SMART im Hintergrund aktiv war (Hintergrundcheck) dann gab es Datenverlust.
Die Evos mit der neuesten Firmware die den Lahmheitsbug endlich verhindern soll (und immer noch nicht tut, je nach Gurkenmodell), shreddert nach dem neuesten Firmwareupdate und fstrim während des bootens auch erfolgreich die Daten, laut einigen Userberichten.
Ich mache fstrim nur noch wenn ich merke das Ding wird wieder zu lahm, das reicht alle paar Wochen bis Monate.
Dann kann man auch noch gucken, dass mein Flash-Dateisystem benutzt.
Wikipedia sagt: For raw flash without a flash translation layer (FTL) or Memory Technology Device (MTD), there is UBIFS, JFFS2, and YAFFS, among others. SquashFS is a common compressed read-only file system.
Hmm da man ja von ein paar SSD abgeraten wird bezüglich SSD-Optimierung usw. welche SSD wäre denn brauchbar ? Da ich eher auf sicher gehen will hätte da ein paar User gute Tipps welche Marke oder Typ von SSD weniger Probleme machen!?.
Ach ja finde den Artikel echt super und interessant.
Solch eine Pauschalaussage lässt sich nicht seriös treffen, auch die im Artikel halte ich für überzogen. SSDs haben zwar die gröbsten Kinderkrankheiten überwunden, aber sind noch immer eine relativ junge Technologie. Regelmäßige Backups sind in jedem Fall ein Muss.
Meine persönlichen Favoriten waren und sind auch weiterhin Modelle von Crucial und Samsung, und beide Marken hatten/haben in den letzen Monaten/Jahren immermal Probleme mit ihren Firmwares gehabt, die lassen sich aber mit etwas Recherche oder Updates beheben oder umgehen (siehe z.B. meinen Kommentar oben). Und wer sich partout nicht damit auseinandersetzen möchte welche SSD-Firmware-Kernel-Kombinationen zu vermeiden sind und ohne Mühe auf Nummer Sicher gehen will, der sollte IMHO auf die bewährtere Techologie (HDDs) setzen.
Vielen Dank für deine Aussage Forecast. Zwischen zeitlich hab ich auch schon meine Suchmaschine bemüht, und die meisten Aussagen die ich so gefunden habe von Usern sind ähnlich deiner. Glaub ich warte doch noch mit den SSD.
Ich hab eine Kingston-SSD (VPro glaub ich heißt die) im Einsatz und bin damit rundum zufrieden. Der Rechner, in dem sie steckt, läuft zwar nur alle paar Wochen, dann darf sie aber richtig schuften (mehrere VMs wollen gleichzeitig lesen und schreiben). Mittlerweile hat sie ca. 700 GB Daten gelesen und 600 geschrieben, läuft noch wie am ersten Tag und an Problemen gab's nur eins, das ich durch Aufräumen lösen konnte.
Und was bitte beweisen 700 GB? Das schreiben andere Systeme an einem Wochenende und hier waren es 1.5 TB von Freitag bis Dienstag (btrf compress-force -> defrag)
Filesystem created: Wed Jun 8 13:10:56 2011 Last mount time: Tue May 19 14:56:26 2015 Last write time: Tue May 19 14:56:26 2015 Lifetime writes: 108 TB
Genau 1 der 4 RAID10-Platten seit 2011 getauscht und das erst kürzlich
C&P klappt nicht ganz. hier fehlt ein leerzeichen: "sudo /sbin/blockdev --getalignoff/dev/sda1"
"relatime" ist default seit Kernel 2.6.30, also "defaults, relatime" ist redundant.
Du wirst es nicht glauben aber es gibt in der Welt da draussen auch eine Zeit vor 2.6.30
2.6.18-404.el5 #1 SMP Tue Apr 7 12:42:54 EDT 2015 x86_64
Recht hat er trotzdem, und da der am meisten gebrauchte "alte" Kernel wohl 2.6.32 ist, hat sein Kommentar hier sehr wohl etwas zu suchen. Kann ja niemand was dafür dass du RHEL5 nutzt (ganz zu schweigen noch im Zusammenhang mit einer SSD)
Einen Schmarren hat er recht - steht doch explizit im Artikel man möge mittels mount schauen ob relatime gesetzt ist und WENN NICHT die Option setzen
Abgesehen davon wüsste ich jetzt nichts was gegen rhel5 spricht nachdem es nun mal eine supportete LTS Distribution ist - BTW nutze ich Fedora, das ändert aber nichts daran dass ich auch über den Tellerrand sehe
"Bei SSDs von Crucial und Micron sollte man auf Trim grundsätzlich verzichten, denn Firmware-Bugs bei einigen Modellen können bei Trim und gleichzeitigen Schreibvorgängen zu Datenverlust führen."
Gibt es dazu ne Quelle? Würde gerne mehr darüber wissen, z.B. welche Modelle betroffen sind.
Mindestens die MX100- und M500/M550-Serien sind offenbar betroffen.
http://forum.crucial.com/t5/Crucial-SSDs/M500-M5x0-QUEUED-TRIM-data-corruption-alert-mostly-for-Linux/td-p/151028/page/2
http://forum.crucial.com/t5/Crucial-SSDs/Possible-MX100-bug-that-Wipes-Partitions/td-p/161861
Der erste Link dreht sich um das sog. "queued trim", auch genannt NCQ-Trim. Das wurde mit SATA-3.1-Spezifikation eingeführt und wird mit normalen Schreib/Lese-Zugriffen quasi gleichgestellt behandelt, um den normalen Betrieb während des trims nicht zu verlangsamen. Die eine oder andere SSD-Firmware funktioniert mit Linux aber offenbar nicht sicher zusammen und es kann dann beim queued Trim zu Datenverlusten kommen.
Der Kernel hält inzwischen in drivers/ata/libata-core.c eine Blacklist von SSDs vor, bei denen queued Trim (noch) nicht funktioniert und deshalb deaktiviert werden muss. Wenn man bei der aktuellen Entwicklungs des Kernels schaut, dann sind davon aber nicht nur mehrere Crucial-Serien betroffen, sondern auch Samsung 8xx-er Serien (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81).
Das normale Trim scheint aber zu funktionieren, und sofern man einen Kernel und SSD zusammen benutzt bei dem queued trim nicht aktiv ist (weil nicht in der SSD vorhanden oder vom Kernel geblacklistet), hat man wohl kein Problem damit. Kernel-Versionen vor 3.12 sind gar nicht betroffen, weil es da noch kein queued trim gab, für spätere muss man auf die Version/Revision/Patches achten was geblacklistet ist, aber evtl. kann auch ein Firmwareupdate der SSD helfen (zumindest bei betroffenen SSDs; bei älteren, die queued trim noch nicht hatten, sollte man ein Update dann gerade unterlassen).
Der zweite Link dreht sich wohl um ein Problem mit der mitgelieferten Windows-Software und ist zumindest für Linux-only-User wohl nicht existent. Bitte hinzufügen, falls jemand noch weitere Datenverlust-Probleme bei SSDs kennt/findet.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 15. Mai 2015 um 12:51.Der "Nachteil", dass man bei fstrim jedes FS einzeln angeben muss, ist eigentlich keiner:
~$ fstrim -va
und gut is.
Der "Nachteil", dass man bei fstrim jedes FS einzeln angeben muss, ist eigentlich keiner:
~$ fstrim -va
und gut is.
Bei manchen SSDs gab es nen Bug wenn gerade SMART im Hintergrund aktiv war (Hintergrundcheck) dann gab es Datenverlust.
Die Evos mit der neuesten Firmware die den Lahmheitsbug endlich verhindern soll (und immer noch nicht tut, je nach Gurkenmodell), shreddert nach dem neuesten Firmwareupdate und fstrim während des bootens auch erfolgreich die Daten, laut einigen Userberichten.
Ich mache fstrim nur noch wenn ich merke das Ding wird wieder zu lahm, das reicht alle paar Wochen bis Monate.
Dann kann man auch noch gucken, dass mein Flash-Dateisystem benutzt.
Wikipedia sagt:
For raw flash without a flash translation layer (FTL) or Memory Technology Device (MTD), there is UBIFS, JFFS2, and YAFFS, among others. SquashFS is a common compressed read-only file system.
Deine SSD ist kein "raw flash"!
Hmm da man ja von ein paar SSD abgeraten wird bezüglich SSD-Optimierung usw. welche SSD wäre denn brauchbar ?
Da ich eher auf sicher gehen will hätte da ein paar User gute Tipps welche Marke oder Typ von SSD weniger Probleme machen!?.
Ach ja finde den Artikel echt super und interessant.
Solch eine Pauschalaussage lässt sich nicht seriös treffen, auch die im Artikel halte ich für überzogen. SSDs haben zwar die gröbsten Kinderkrankheiten überwunden, aber sind noch immer eine relativ junge Technologie. Regelmäßige Backups sind in jedem Fall ein Muss.
Meine persönlichen Favoriten waren und sind auch weiterhin Modelle von Crucial und Samsung, und beide Marken hatten/haben in den letzen Monaten/Jahren immermal Probleme mit ihren Firmwares gehabt, die lassen sich aber mit etwas Recherche oder Updates beheben oder umgehen (siehe z.B. meinen Kommentar oben). Und wer sich partout nicht damit auseinandersetzen möchte welche SSD-Firmware-Kernel-Kombinationen zu vermeiden sind und ohne Mühe auf Nummer Sicher gehen will, der sollte IMHO auf die bewährtere Techologie (HDDs) setzen.
Vielen Dank für deine Aussage Forecast. Zwischen zeitlich hab ich auch schon meine Suchmaschine bemüht, und die meisten Aussagen die ich so gefunden habe von Usern sind ähnlich deiner. Glaub ich warte doch noch mit den SSD.
Ich hab eine Kingston-SSD (VPro glaub ich heißt die) im Einsatz und bin damit rundum zufrieden. Der Rechner, in dem sie steckt, läuft zwar nur alle paar Wochen, dann darf sie aber richtig schuften (mehrere VMs wollen gleichzeitig lesen und schreiben). Mittlerweile hat sie ca. 700 GB Daten gelesen und 600 geschrieben, läuft noch wie am ersten Tag und an Problemen gab's nur eins, das ich durch Aufräumen lösen konnte.
Grueße
Ignatz
Und was bitte beweisen 700 GB?
Das schreiben andere Systeme an einem Wochenende und hier waren es 1.5 TB von Freitag bis Dienstag (btrf compress-force -> defrag)
Filesystem created: Wed Jun 8 13:10:56 2011
Last mount time: Tue May 19 14:56:26 2015
Last write time: Tue May 19 14:56:26 2015
Lifetime writes: 108 TB
Genau 1 der 4 RAID10-Platten seit 2011 getauscht und das erst kürzlich
Vielen Dank für den tollen Artikel! Für mich war der sehr informativ und lehrreich! Es wäre schön, wenn es davon mehr geben würde!