ubuntuusers.de

hallo ☹

mein eigentliches ziel: automatischen täglichen SSD Trim aktivieren.

stattdessen werden mir im verzeichnis "/etc/cron.daily/" jetzt 2 dateien angezeigt ,1. "batched_discard.save" und 2. "batched_discard.save.1" , die sich nicht mehr ändern oder löschen lassen.

und der automatische "trim" noch immer nicht läuft.

kann mir bitte jemand mitteilen , welche fehler ich jetzt wieder gemacht habe ?

vielen dank ☹

meinertreu74 schrieb:

mein eigentliches ziel: automatischen täglichen SSD Trim aktivieren.

Sollte das nicht mittlerweile eh von Haus aus passieren? Mit

 systemctl list-timers 

sollte dir ein fstrim.timer angezeigt werden, der einen fstrim.service aufruft.

kann mir bitte jemand mitteilen , welche fehler ich jetzt wieder gemacht habe ?

Das kommt drauf an, was Du getan hast um den jetzigen Zustand zu erreichen.

hallo Into_the_pit ... und vielen dank für deine antwort.

mit

systemctl list-timers

bekomme ich folgende ausgabe:

NEXT                          LEFT          LAST                          PASSED       UNIT                  
Fri 2018-09-21 19:02:37 CEST  11min left    Fri 2018-09-21 18:02:10 CEST  48min ago    anacron.timer         
Fri 2018-09-21 22:20:33 CEST  3h 29min left Fri 2018-09-21 13:08:55 CEST  5h 42min ago apt-daily.timer       
Sat 2018-09-22 02:43:38 CEST  7h left       Fri 2018-09-21 13:47:00 CEST  5h 3min ago  motd-news.timer       
Sat 2018-09-22 06:52:25 CEST  12h left      Fri 2018-09-21 13:08:55 CEST  5h 42min ago apt-daily-upgrade.time
Sat 2018-09-22 13:23:56 CEST  18h left      Fri 2018-09-21 13:23:56 CEST  5h 27min ago systemd-tmpfiles-clean
Mon 2018-09-24 00:00:00 CEST  2 days left   Mon 2018-09-17 00:00:37 CEST  4 days ago   fstrim.timer          
n/a                           n/a           Fri 2018-09-21 13:09:45 CEST  5h 41min ago ureadahead-stop.timer 

7 timers listed.
Pass --all to see loaded but inactive timers, too.
~
~
~
~
~
~
~
~
~
~
~
~

anscheinend ist ein wochen-takt aktiv , nur leider ist das zu wenig.

ich habe vorhin den fstrim manuell ausgeführt mit:

sudo fstrim -v /

als ausgabe –> 118 GB getrimmt das gleiche machte ich mit "/home"

das system hat nicht mehr reagiert ,deswegen musste ich den fstrim manuell ausführen

meinertreu74 schrieb:

anscheinend ist ein wochen-takt aktiv , nur leider ist das zu wenig.

Was lässt Dich das glauben, es sei zu wenig?

das system hat nicht mehr reagiert ,deswegen musste ich den fstrim manuell ausführen

Und Du glaubst das liegt an den belegten Blöcken? Welche SSD nutzt Du und wie ist die Ausgabe von

 sudo smartctl -a /dev/sdx 

(sdx bitte sinnvoll an Dein Syste anpassen).

vorher unter ubuntu 16.04 hab ich den fstrim 1x täglich durchführen lassen und es wäre toll ,wenn ich das hier auch könnte.

SSD : samsung SSD 840 pro 250 GB = Linux installiert mit 2 partitionen : 1x / und 1x /home –→ /dev/sda.

als ich

sudo smartctl -a /dev/sda

im terminal eingeben habe kam folgende ausgabe:

xxxxxxx@RO8XW4M0G5:~$ sudo smartctl -a /dev/sda
sudo: smartctl: Befehl nicht gefunden

meinertreu74 schrieb:

vorher unter ubuntu 16.04 hab ich den fstrim 1x täglich durchführen lassen und es wäre toll ,wenn ich das hier auch könnte.

Dann musst Du den fstrim.timer entsprechend anpassen.

xxxxxxx@RO8XW4M0G5:~$ sudo smartctl -a /dev/sda
sudo: smartctl: Befehl nicht gefunden

Das Paket smartmontools fehlt, das muss Du für den Befehl erst installieren.

und bitte wo kann man den fstrim.timer aufrufen ?

ich habe leider überhaupt keine ahnung , was das überhaupt ist .in den einstellungen ist nichts zu finden.

meinertreu74 schrieb:

und bitte wo kann man den fstrim.timer aufrufen ?

Der .timer ist ein systemd-Unit und kann entweder direkt bearbeitet werden (systemd/Units (Abschnitt „Bestehende-Unit-editieren“)) oder man legt sich selber einen separaten an. Einstellungen für den Timer-Unit findest Du unter systemd/Timer Units.

meinertreu74 schrieb:

anscheinend ist ein wochen-takt aktiv , nur leider ist das zu wenig.

Normalerweise reicht wöchentlich, oder gar monatlich, locker aus.

als ausgabe –> 118 GB getrimmt

Die Ausgabe hat nichts zu sagen. Je nach Dateisystem ist es völlig normal, daß immer (oder zumindest einmal pro Neustart) der gesamte freie Speicher getrimmt wird.

das system hat nicht mehr reagiert ,deswegen musste ich den fstrim manuell ausführen

Das ist ein anderes Problem. Selbst wenn du NIE trimmst, sollte der Fall daß das System nicht mehr reagiert, nicht eintreten.

Die SSD wird höchstens ein bißchen langsamer (was man außerhalb von Benchmarks gar nicht merkt) und sonst ändert sich nichts.

*

TRIM ist leider zu einer Religion geworden. Einfach nur Panik wegen scheinbar niedriger Schreibzyklen gekoppelt mit astronomisch hohen Preisen (als 64GB noch soviel kosteten wie 512GB heute). Überall wird TRIM ausgeführt, ganz ungefragt bei mkfs, bei LVM wenn man LVs verändert (wegen issue_discards=1 was man auf 0 setzen sollte), und eben mit dem Timer im Hintergrund, von dem man gar nichts weiß. Oder es wird gar gleich mit discard-Flag gemountet.

Das hat dann die Folge, daß du nach einem Datenunfall einfach nichts mehr wiederherstellen kannst. Wer eine SSD hat, aber kein Backup, der ist noch viel aufgeschmissener als bei HDDs, wo man Daten oft doch noch retten kann. Bei SSD keine Chance und das nur, weil alle Daten ohne Sinn und Verstand sofort weggekippt werden.

Man hat wirklich überhaupt gar keine Vorteile davon, die SSD ständig zu trimmen.

vielen dank into_the_pit

habe die datei fstrim.timer im verzeichnis /lib/systemd/system/ abgeändert und per

sudo systemctl enable fstrim.timer

und

sudo systemctl start fstrim.timer

wieder aktiviert und gestartet.

frostschutz : ich habe auf den beiden SSD's nur das jeweilige betriebssystem drauf , die anderen dinge sind auf normalen festplatten verteilt. sollte die SSD "hops" gehen , installiere ich das system halt neu. 😉

vielen dank , an euch beide