SSD wöchentliches TRIM per fstrim.timer

Anonymous · 7 Mai 2015

Hallo Leute!

Ich benötige mal Eure Hilfe.

Ich will meine SSD wöchentlich trimmen lassen statt permanent über discard.
Für opensuse 13.2 gibt es einen Service der fstrim.timer heißt.
http://software.opensuse.org/package/util-linux-systemd
Man muss ihn so aktivieren:

Code:

systemctl enable fstrim.service
systemctl start fstrim.service

Kann ich den auch irgendwie für opensuse 13.1 installieren?

spoensche · 8 Mai 2015

LUH 3417 schrieb:
Kann ich den auch irgendwie für opensuse 13.1 installieren?

Wenn er nicht als Paket vorhanden ist, bleibt die nur die Installation zu Fuss, also ggf. manuell Compilieren. Was spricht den gegen Discard? Die Lebensdauer deiner SSD beeinflusst es jedenfalls nicht.

josef-wien · 8 Mai 2015

Ich denke, der Kernel ist besser informiert, wann sinnvollerweise trim-Befehle an den SSD-Controller gerichtet werden sollen. Ein wöchentlicher Sammelauftrag muß viel mehr Arbeit leisten und kann durchaus zum "falschen" Zeitpunkt laufen.

Welchen wie üblich komplizierten Mechanismus sich systemd bei 13.2 ausgedacht hat, entzieht sich meiner Kenntnis. Eine vernünftige Lösung mit einem cron job, der die entsprechenden Befehle

/usr/sbin/fstrim einhängepunkt

(den Parameter -a kennt die Version von 13.1 noch nicht) ausführt, wird es wohl nicht sein.

Was ist eigentlich Deine Motivation?

Anonymous · 9 Mai 2015

Meine Motivation, also wenn ich versehentlich was gelöscht habe nützt mir photorec nichts mehr mit DISCARD.
Aber ich bin ja keine Spezialistin in Linux. :blush:

Sowas dauert.

Rainer Juhser · 9 Mai 2015

LUH 3417 schrieb:
wenn ich versehentlich was gelöscht habe

Dagegen hilft ein regelmäßiges Backup. Am besten auch automatisiert über einen Cronjob.

Anonymous · 9 Mai 2015

@Rainer Juhser
Richtig, aber eine Datei die photorec zurückholt, ist aktueller als eine Sicherungskopie.
Und beim regelmäßigen Backup über einen Cronjob überschreibt man auch alte Versionen, die dann futsch sind.

Ich verstehe schon, was LUH 3417 meint:
Mit discard als mount-Option braucht man photorec gar nicht erst bemühen. Die Daten sind wie ein Sandkorn, das man in einen Sandhaufen geworden hat.
Wenn openSUSE ab Version 13.2 Trim per systemd anbietet — das ist doch eine gute Idee von ihr, das für 13.1 zu übernehmen!

josef-wien · 9 Mai 2015

rolandb schrieb:
Und beim regelmäßigen Backup über einen Cronjob überschreibt man auch alte Versionen

Das kommt auf die verwendete Variante an.

rolandb schrieb:
Mit discard als mount-Option braucht man photorec gar nicht erst bemühen.

Das hängt jetzt von der SSD-firmware ab. Physisch wird in der Belegungstabelle die Speicherzelle als "nicht mehr aktuell" markiert, der Inhalt der Speicherzelle selbst bleibt unverändert (und zwar solange, bis entweder die nur als Einheit löschbare zusammengehörige Gruppe von Speicherzellen vollständig "nicht mehr aktuell" ist und daher gelöscht werden kann oder bis die garbage collection diese Gruppe löscht, nachdem sie den Inhalt der noch belegten Speicherzellen in leere Speicherzellen einer anderen Gruppe kopiert hat). Ob aber die SSD-firmware beim Lesen den unaktuellen Inhalt oder aber "leer" meldet, wird wohl jeder Hersteller invididuell handhaben.

Anonymous · 10 Mai 2015

Richtig. Trim gibt nur die Info an den Controller der SSD weiter.
Aber welche SSD soll man dann am besten kaufen?

So oder so: Wenn Trim erst mal abgesetzt ist, gehen die Chancen einer Wiederherstellung von Daten schlagartig gegen Null.
Wer LUH 3417 wohl diesen Tipp mit systemd & openSUSE13.2 gegeben hat?

spoensche · 10 Mai 2015

rolandb schrieb:
Richtig. Trim gibt nur die Info an den Controller der SSD weiter.
Aber welche SSD soll man dann am besten kaufen?

Die heutigen SSD's unterscheiden sich i.d.R. nur durch die verbauten NAND- Speicherzellen, dem Hersteller, dem einen mehr oder weniger wichtigen fehlenden oder vorhandenen Feature und vom Preis, der aber auch abhängig vom Namen des Herstellers ist.

Also prinzipiell bist du mit OCZ, Samsung oder Crucial auf der sicheren Seite.
Preislich ist von der "Oberklasse" über die "Mittelschicht" bis zum "günstigen" "Leistungstier" bei den genannten alles dabei. Wer wohl in welcher Kategorie beheimatet ist?

Anonymous · 10 Mai 2015

Hi spoensche,
ich habe eine Samsung 840 EVO 250GB. Soll ich lieber discard drinlassen in /etc/fstab ?
Im Ubuntuusers-wiki http://wiki.ubuntuusers.de/SSD/TRIM steht Samsung nicht auf der Nagativliste.

norritt · 10 Mai 2015

Also ich bin seit nem knappen Jahr mit ner 840 EVO bei aktiviertem discard unterwegs - läuft alles prima bisher =)

Boreas · 11 Mai 2015

Wenn Du das unter 13.1 machen willst, gibt natürlich mehrere Möglichkeiten, die hier genannten will ich wiederholen.
Da ich lernen wollte besser mit systemd umzugehen habe ich einen eigenen Dienst erstellt, der letztlich über ein kleines einfaches
Skript das Trimmen regelt. Das Skript ist lediglich im Hinblick auf die gewünschte Häufigkeit des Trimmens ergänzt, ansonsten entspricht
es dem Skript hier:http://wiki.ubuntuusers.de/SSD/TRIM
Im übrigen findet man im Netz unzählige Quellen über das Trimmen im Allgemeinen und das Für und wieder mittels discard. Ich kann
das fachlich nicht beurteilen. Meiner Meinung nach ist es wichtiger unnötige Schreibvorgänge gar nicht erst zuzulassen.

Anonymous · 11 Mai 2015

Hi Boreas,
bei der Samsung 840 EVO mit 250 GB kann ich 5 Jahre lang jeden Tag 20 GB Daten schreiben.

Danke für Deinen Tipp. Ich werde mir auch einfach ein Script eintippen. Gibts ja schon fertig.
Ich dachte halt mit fstrim.timer über den systemd wäre das vielleicht besser.

Boreas · 15 Mai 2015

@ LUH 3417,
ich lasse das Skript (siehe unten) durch die Datei

Code:

/etc/init.d/after.local

aufrufen

Code:

/etc/init.d/trim.sh

dazu muss jedoch zuerst after.local durch systemd auch aufgerufen werden, also

Code:

systemctl enable after-local.service

- ab jetzt wird jeweils zum Systemstart das Skript trim.sh ausgeführt.

das Trim-Skript:

Code:

#! /bin/bash
log_dateiname=/var/log/trim.log
#Sekunden eines Tages
tag=86400
#trim soll alle $zeitsprung Tage ausgeführt werden
zeitsprung=7
#Prüfen, ob $log_dateiname existiert
if [ -f $log_dateiname ]; then
  #Datum der letzten Dateiänderung in Variablen ablegen
  log_zeit=`date -r $log_dateiname +%s`
  #aktuelles Datum in Variablen ablegen
  ist_zeit=`date +%s`
  #Vergleichen
  if [ $((($ist_zeit-$log_zeit) / $tag)) -ge $zeitsprung ]; then
    echo "*** $(date -R) ***" >> $log_dateiname
    fstrim -v / >> $log_dateiname
    fstrim -v /home >> $log_dateiname
  else
    echo "*** $(date -R) *** Zeitraum für Trimmen noch nicht abgelaufen!" >> $log_dateiname
  fi
else
  echo "*** $(date -R) ***" >> $log_dateiname
  fstrim -v / >> $log_dateiname
  fstrim -v /home >> $log_dateiname
fi

Sauerland · 15 Mai 2015

http://www.pro-linux.de/artikel/2/1767/tipps-zur-ssd-optimierung.html

josef-wien · 15 Mai 2015

Die üblichen journalistischen Halbwahrheiten (zur Verunsicherung der Leute).

Boreas schrieb:
/etc/init.d/after.local
/etc/init.d/trim.sh

1. Doppelt gemoppelt?
2. Ein cron job macht das mit deutlich weniger Erstellungsaufwand.

Anonymous · 16 Mai 2015

Sauerland schrieb:
http://www.pro-linux.de/artikel/2/1767/tipps-zur-ssd-optimierung.html

Der Artikel enthält leider pauschalisiert dagestellte altbackene Tipps:

Ein für eine SSD oder eine HDD mit internen 4k-Blöcken ungünstiges Alignment von 63 Sektoren (statt 64 oder 2048) bekommt man nur, wenn das Laufwerk unter < win6.1 partitioniert wurde oder mit einer uralten parted Version z.B. auf SystemRescueCD 0.3.1.
Die mount Option relatime wird seit Jahren vom Linux-Kernel automatisch benutzt, wenn nicht anderes angegeben wird.
Diese Art de Zeitstempelaktualisierung findet somit längst auch bei Festplatten Anwendung und reduziert dadurch unötig viele Kopfbewegungen, die immer (Zugriffs-)Zeit bedeuten.
Für die beiden Crucial SSDs M550 und MX100 gibt es schon lange ein Firmwareupdate. Der Blacklisteintrag im Kernel kann/darf dann auskommentiert werden.

Sehr aktuell dagegen ist diese Information zum TRIM:

pro-linux.de/artikel/2/1767 schrieb:
Die Methode per Cron-Job: Diese elegante Methode ist bei Ubuntu 14.04/14.10 und dessen Ablegern bereits Standard und richtet einen wiederkehrenden Cron-Job für fstrim ein, der einmal pro Woche automatisch abläuft, allerdings nur auf SSDs von Samsung und Intel. Dafür ist das Skript /etc/cron.weekly/fstrim verantwortlich. Fedora 21 und Opensuse 13.2 erledigen dies über Systemd und dessen Dienst fstrim.service. Bei diesen Distributionen muss man sich um Trim also keine Gedanken machen.

→ systemd: fstrim.timer

Anmerkung:

Es gibt keinen Grund, alle Crucial SSDs generell von der automatischen TRIM-Einrichtung per Cron Job oder systemd auszugrenzen.

josef-wien · 16 Mai 2015

Ergänzung: Die Probleme bei einigen Micron/Crucial-SSD sowie der Samsung 850 PRO-SSD betreffen nur das mit der ATA-Spezifikation 3.1 zusätzlich eingeführte queued TRIM (die ursprünglichen, als non-queueable definierten Anweisungen funktionieren auch bei diesen SSD).

rolandb schrieb:
Der Blacklisteintrag im Kernel kann/darf dann auskommentiert werden.

Das werden die Kernel-Entwickler sicher nicht machen, nicht jeder Benutzer hat den Mut zu einem firmware update, und die meisten haben von dem Problem nicht einmal eine Ahnung. Bei "problematischer" firmware wird der Kernel weiterhin mit non-queueable commands arbeiten.

Anonymous · 16 Mai 2015

Wo findet man diese Kernel-Blacklist vom installieren Linux-Kernel?
In /usr/src/linux-3.11.10-29/drivers/ata/libata-core.c steht das bei mir gar nicht.

o_schwarze-liste-im-kernel-quellcode-mit-dem-trim-befehl-wird-heute-deutlich-.jpg

Anonymous · 16 Mai 2015

LUH 3417 schrieb:
Wo findet man diese Kernel-Blacklist vom installieren Linux-Kernel?

Im aktuellen openSUSE Kernel. Hier: 4.0.3-1.1.g3ee3773

Code:

	/* devices that don't properly handle queued TRIM commands */
	{ "Micron_M500*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Crucial_CT*M500*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Micron_M5[15]0*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Crucial_CT*M550*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Crucial_CT*MX100*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },
	{ "Samsung SSD 850 PRO*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
						ATA_HORKAGE_ZERO_AFTER_TRIM, },

Man sieht hier, dass beispielsweise bei der Crucial MX100 explizit die Firmwareversion "MU01" abgefragt wird. Aktuell ist aber "MU02".
Erstaunlich, dass es u.a. die relativ neue Samsung SSD 850 PRO auch in die Liste geschafft hat.

In /usr/src/linux-3.11.10-29/drivers/ata/libata-core.c steht das bei mir gar nicht.

Keine Ahnung, warum die Blacklist dort fehlt.

SSD wöchentliches TRIM per fstrim.timer

Anonymous

Gast

Moderator

Ultimate Guru

Anonymous

Gast

Moderator

Anonymous

Gast

Ultimate Guru

Anonymous

Gast

Moderator

Anonymous

Gast

Member

Member

Anonymous

Gast

Member

Ultimate Guru

Ultimate Guru

Anonymous

Gast

Ultimate Guru

Anonymous

Gast

Anonymous

Gast