Arch Linux

Frage: SSD, TRIM, fstab

Silmaril

Zu was sollte es gut sein, den Bereich mit Nullern zu überschreiben?

Kabbone

Weil so die Funktionsweise von Flash Speichern ist? So sparst du dir beim neuen beschreiben die Zeit zum Löschen.
http://de.wikipedia.org/wiki/Flash-Speicher#Ansteuerung

Ovion

Ok, es kommt hier auf die Definition von "Schreiben" an. Ich würde hier nicht von "Überschreiben" mit Nullen sprechen, eher von zurücksetzen, denn diese Nullenflut ist ja keine Schreibzyklusabnutzung, wenn ich das richtig verstanden habe?

[gelöscht]

Nutzt bei der SSD doch btrfs, dann braucht ihr nicht mehr weiter zu reden (schreiben). Btrfs kennt kein discard nutzt die Option ssd und ist für ssd optimierter.

Mount-Option -o ssd
 - achtet nicht mehr darauf, die Fragmentierung des Dateisystems gering zu halten (das spart Zeit und Metadaten und ist bei SSDs nicht relevant)
 - versucht beim Schreiben bereits zuvor genützte Blöcke zu verwenden
 - Tests von Phoronix zeigten im Mai 2009 mit Kernel 2.6.29.4 dass Btrfs mit SSD Option langsamer ist als ohne dieser Option.[3] Der SSD Code wurde im Zuge von 2.6.30-rc verbessert und soll nun tatsächlich 
    einen Performancezuwachs bringen.
        
Mount-Option -o ssd_spread
 - platziert neue Extents in Bereiche die vollständig leer sind
 - erhöht die Wahrscheinlichkeit einen kompletten Erase Block der SSD auf einmal zu beschreiben (kann Vorteile bei SSDs der ersten Generation bringen, bei neueren SSDs nicht sinnvoll)

gelesen auf den Seiten von Thomas Krenn (Wiki)

Ovion

Solange es von btrfs kein Stable gibt, ist das, zumindest für mich, nicht wirklich 'ne Option.

Creshal

Und täglich grüßt das Desinformations-Murmeltier… TRIM für Verschwörungsthoeretiker erklärt: https://forum.archlinux.de/viewtopic.php?pid=313325#p313325

[gelöscht]

Ovion schriebSolange es von btrfs kein Stable gibt, ist das, zumindest für mich, nicht wirklich 'ne Option.

Wie stable muß es den sein wenn SuSE Enterprise Server es bereits verwendet?

Silmaril

Danke Creshal. Hätte mich auch gewundert, wenn die SSD beim trimmen gleich löschen würde.

Der Link von Kabbone ist aber trotzdem grundsätzlich interessant.

Zu btrfs: Ich hab mir beim Aufsetzen dieses Systems noch dagegen entschieden, weil die Tools dafür noch nicht so ausgereift sind. Aber grundsätzlich ist das das Dateisystem welches recht bald dominieren wird.

Ovion

Wenn die Kernel-Guys sagen, es gibt noch kein Stable-Release, dann werden sie ihren Grund haben. Ich habe nicht genug Ahnung von der Technik, aber ich gehe davon aus, dass die entsprechenden Kernel-Guys Ahnung haben und ihre Gründe für diese Entscheidung haben. Das Ding mag, wie die Kernel-FAQ auch sagt, hinreichend stabil sein, aber die Kennzeichnung experimental hat ext4 bspw. nicht. Ich für meinen Teil warte, bis btrfs ebenfalls nicht mehr experimental ist. Dateisystemversagen ist eine der wenigen Dinge, die Dinge (meine Daten) wirklich irreversibel kaputtmachen können.

Kabbone

Laut der letzten Messung von Phoronix ist brtfs auch nicht schneller als ext4, sondern teilweise sogar langsamer und ich für meinen Teil vertraue im Moment noch etwas mehr auf ext4.

Bei dem "Löschen" habt ihr natürlich Recht, ist eher ein Rücksetzen und sollte noch keinen Einfluss auf die Lebensdauer haben.

[gelöscht]

@Ovion, hier wird es als stable deklariert https://btrfs.wiki.kernel.org/index.php/Main_Page
@Kabbone, ja es ist etwas langsamer aber es ist auch optimierter für eben SSD's und kommt ohne discard aus
Ich habe es mir mal eingerichtet und werde nun mal ein Jahr testen, ohne fstrim und co..

Ovion

Klingt für mich eher nach später Beta, um ehrlich zu sein. API ändert sich nicht mehr, aber "Every effort is being made to keep it stable and fast".

Kabbone

Es mag optimierter für SSD's sein, aber ja nur in Bezug auf Lebensdauer/Abnutzung und die Zyklen deiner SSD solltest du kaum vollkriegen in ihrer Anwendungszeit, deswegen sehe ich auch keinen Grund im Moment dem ganzen eine Chance zu geben.

« Vorherige Seite