Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Tipps zur SSD-Optimierung

19 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Linksschreiber am Do, 14. Mai 2015 um 15:46 #

C&P klappt nicht ganz. hier fehlt ein leerzeichen: "sudo /sbin/blockdev --getalignoff/dev/sda1" :P

0
Von cptwunderlich am Do, 14. Mai 2015 um 17:15 #

"relatime" ist default seit Kernel 2.6.30, also "defaults, relatime" ist redundant.

  • 0
    Von Verflucht am Do, 14. Mai 2015 um 18:31 #

    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

    0
    Von blablabla233 am Fr, 15. Mai 2015 um 10:09 #

    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)

    • 0
      Von Verflucht am Fr, 15. Mai 2015 um 21:55 #

      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

0
Von Forecast am Do, 14. Mai 2015 um 18:47 #

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

  • 0
    Von Gaufnz am Fr, 15. Mai 2015 um 10:13 #

    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

    • 0
      Von Forecast am Fr, 15. Mai 2015 um 12:29 #

      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.
0
Von Marc-nichteingeloggt am Do, 14. Mai 2015 um 20:30 #

Der "Nachteil", dass man bei fstrim jedes FS einzeln angeben muss, ist eigentlich keiner:

~$ fstrim -va

und gut is.

0
Von Marc-nichteingeloggt am Do, 14. Mai 2015 um 20:30 #

Der "Nachteil", dass man bei fstrim jedes FS einzeln angeben muss, ist eigentlich keiner:

~$ fstrim -va

und gut is.

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

0
Von allo am Do, 14. Mai 2015 um 23:26 #

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.

0
Von Anonymous am Fr, 15. Mai 2015 um 15:55 #

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.

  • 0
    Von Forecast am Fr, 15. Mai 2015 um 19:19 #

    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.

    0
    Von Anonymous am Mo, 18. Mai 2015 um 14:58 #

    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

    • 0
      Von Verflucht am Di, 19. Mai 2015 um 15:15 #

      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

0
Von anon am So, 17. Mai 2015 um 22:45 #

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!

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung