Hi, mein guter alter Asus-eeepc läuft aktuell unter leap 15.1. Meist fahre ich ihn mit suspend to disk runter, geht auch soweit, aber ich habe ihm eine SSD spendiert und gelesen, dass die dadurch halt doch mehr belastet wird, weil ja jedesmal der ganze aktuelle Kernelzustand drauf muss. Kann man das konfigurieren? Im Netz habe ich nur einen veralteten Artikel zu s2disk gefunden, nichts zu 15.x. Ich würde gern 1. ein device für den Kernelabzug festlegen (und dafür dann eine SD-Karte in den meist ohnehin ungenutzten Schacht stecken) 2. das ganze von der Cmdline aufrufen... Kennt sich da jemand aus? Thx für jeden Tipp, gern auch ein RTFM mit Angabe des M ;-) -- cu jth
Am 16.06.21 um 07:50 schrieb Jörg Thümmler:
Hi,
mein guter alter Asus-eeepc läuft aktuell unter leap 15.1. Meist fahre ich ihn mit suspend to disk runter, geht auch soweit, aber ich habe ihm eine SSD spendiert und gelesen, dass die dadurch halt doch mehr belastet wird, weil ja jedesmal der ganze aktuelle Kernelzustand drauf muss.
Kann man das konfigurieren? Im Netz habe ich nur einen veralteten Artikel zu s2disk gefunden, nichts zu 15.x.
Ich würde gern
1. ein device für den Kernelabzug festlegen (und dafür dann eine SD-Karte in den meist ohnehin ungenutzten Schacht stecken)
2. das ganze von der Cmdline aufrufen...
Kennt sich da jemand aus?
Thx für jeden Tipp, gern auch ein RTFM mit Angabe des M ;-)
Die Daten kommen in beiden Fällen von der SSD, die diese vermutlich schneller liefern kann, als sie vom Prozessor verarbeitet werden. Wie wäre es mit einem Test zur Startdauer mit und ohne suspend to disk. Ich vermute, der Unterschied dürfte minimal sein. Peter ps Dein Leap 15.1 ist schon länger ohne Sicherheitsupdates. Hier wird gelegentlich ein Asus-eeePC 901 genutzt, unter Debian XFCE, stable, mit regulären Sicherheitsupdates und wesentlich längeren Upgradezyklen.
Am 16.06.21 um 13:24 schrieb Peter McD:
Am 16.06.21 um 07:50 schrieb Jörg Thümmler:
Hi,
mein guter alter Asus-eeepc läuft aktuell unter leap 15.1. Meist fahre ich ihn mit suspend to disk runter, geht auch soweit, aber ich habe ihm eine SSD spendiert und gelesen, dass die dadurch halt doch mehr belastet wird, weil ja jedesmal der ganze aktuelle Kernelzustand drauf muss.
Kann man das konfigurieren? Im Netz habe ich nur einen veralteten Artikel zu s2disk gefunden, nichts zu 15.x.
Ich würde gern
1. ein device für den Kernelabzug festlegen (und dafür dann eine SD-Karte in den meist ohnehin ungenutzten Schacht stecken)
2. das ganze von der Cmdline aufrufen...
Kennt sich da jemand aus?
Thx für jeden Tipp, gern auch ein RTFM mit Angabe des M ;-)
Die Daten kommen in beiden Fällen von der SSD, die diese vermutlich schneller liefern kann, als sie vom Prozessor verarbeitet werden.
Wie wäre es mit einem Test zur Startdauer mit und ohne suspend to disk. Ich vermute, der Unterschied dürfte minimal sein.
Peter
ps Dein Leap 15.1 ist schon länger ohne Sicherheitsupdates. Hier wird gelegentlich ein Asus-eeePC 901 genutzt, unter Debian XFCE, stable, mit regulären Sicherheitsupdates und wesentlich längeren Upgradezyklen.
Hi, danke, es geht mir weniger um die Zeit, ich möchte meist einfach da weitermachen, wo ich das letzte Mal aufgehört habe. Und das Starten mancher Programme dauert auf der Kiste manchmal recht lange. Zu Deinem ps: Danke auch dafür, da mach ich mir aber nicht so Sorgen... bis zur SSD lief die Kiste auf 12.3. Ich brauche auf dem eeePC auch nicht die neueste Software und gestatte keine Zugriffe von außen, ehrlich gesagt, ist es ziemlich selten, dass ich damit auch nur eine Webseite aufrufe... Andererseits musste ich jetzt mal einen Webserver mit Debian aufsetzen, das ging ganz gut, aber am Desktop ist mir Suse doch vertrauter... Generell finde ich eine etwas "abgehangene" Distri immer angenehmer, und was hier über 15.3 über die Liste geht, möchte ich nicht auf meinem Arbeitsserver erleben ;-) Ich such mir immer eine raus und teste die erstmal ausgiebig, wenn ich glaube, dass sie passt, plane ich ein Serverupgrade, mache mir eine Parallelinstallation und erst, wenn alle Scripte etc. passen, ziehe ich die heißen Daten rüber. Dadurch geht meine Distri-Folge langsamer, aber ich bin hier darauf angewiesen, dass auch alte Dinge reibungslos klappen. Da kann eine neue Version von samba oder php schon ganz schön Ärger machen. Und man trennt sich ungern von einer gut getesteten Firewall... Bis jetzt habe ich seit, ich glaube 2001: 6.3, 8.1, 11.4 evergreen, 15.1... -- cu jth
Am 16.06.21 um 16:26 schrieb Jörg Thümmler:
Am 16.06.21 um 13:24 schrieb Peter McD:
... ps Dein Leap 15.1 ist schon länger ohne Sicherheitsupdates. Hier wird gelegentlich ein Asus-eeePC 901 genutzt, unter Debian XFCE, stable, mit regulären Sicherheitsupdates und wesentlich längeren Upgradezyklen.
danke, es geht mir weniger um die Zeit, ich möchte meist einfach da weitermachen, wo ich das letzte Mal aufgehört habe. Und das Starten mancher Programme dauert auf der Kiste manchmal recht lange.
zumindest unter KDE, was die GUI betrifft: Systemeinstellungen - Arbeitsflächensitzung - Bei der Anmeldung - vorherige Sitzung wiederherstellen. Andererseits wird Du nicht unbedingt KDE mit einem Asus-eeePC verwenden. Meiner hier tut es, quälend, mit XFCE, ist aber auch nur ein "Notfallrechner".
Generell finde ich eine etwas "abgehangene" Distri immer angenehmer, und was hier über 15.3 über die Liste geht, möchte ich nicht auf meinem Arbeitsserver erleben ;-) ...
Bis jetzt hängt nur Bluetooth in Leap 15.3, Desktop, nicht zu vergleichen mit Serveranforderungen.
Ich such mir immer eine raus und teste die erstmal ausgiebig, wenn ich glaube, dass sie passt, plane ich ein Serverupgrade, mache mir eine Parallelinstallation und erst, wenn alle Scripte etc. passen, ziehe ich die heißen Daten rüber. ... ... Und man trennt sich ungern von einer gut getesteten Firewall... Bis jetzt habe ich seit, ich glaube 2001: 6.3, 8.1, 11.4 evergreen, 15.1...
Alle Achtung! Peter
Am 16.06.21 um 17:37 schrieb Peter McD:
Am 16.06.21 um 16:26 schrieb Jörg Thümmler:
Am 16.06.21 um 13:24 schrieb Peter McD:
... ps Dein Leap 15.1 ist schon länger ohne Sicherheitsupdates. Hier wird gelegentlich ein Asus-eeePC 901 genutzt, unter Debian XFCE, stable, mit regulären Sicherheitsupdates und wesentlich längeren Upgradezyklen.
danke, es geht mir weniger um die Zeit, ich möchte meist einfach da weitermachen, wo ich das letzte Mal aufgehört habe. Und das Starten mancher Programme dauert auf der Kiste manchmal recht lange.
zumindest unter KDE, was die GUI betrifft: Systemeinstellungen - Arbeitsflächensitzung - Bei der Anmeldung - vorherige Sitzung wiederherstellen. Andererseits wird Du nicht unbedingt KDE mit einem Asus-eeePC verwenden. Meiner hier tut es, quälend, mit XFCE, ist aber auch nur ein "Notfallrechner".
Generell finde ich eine etwas "abgehangene" Distri immer angenehmer, und was hier über 15.3 über die Liste geht, möchte ich nicht auf meinem Arbeitsserver erleben ;-) ...
Bis jetzt hängt nur Bluetooth in Leap 15.3, Desktop, nicht zu vergleichen mit Serveranforderungen.
Ich such mir immer eine raus und teste die erstmal ausgiebig, wenn ich glaube, dass sie passt, plane ich ein Serverupgrade, mache mir eine Parallelinstallation und erst, wenn alle Scripte etc. passen, ziehe ich die heißen Daten rüber. ... ... Und man trennt sich ungern von einer gut getesteten Firewall... Bis jetzt habe ich seit, ich glaube 2001: 6.3, 8.1, 11.4 evergreen, 15.1...
Alle Achtung!
Peter
Hi, ist XFCE bei mir. Da geht das auch, ist aber nicht das Gleiche. Beim Aufwachen aus dem Suspend ist der Desktop mit allen Anwendungen gefühlt 2s nach dem Finish der initrd da... -- cu jth
Am 16.06.21 um 07:50 schrieb Jörg Thümmler:
... 2. das ganze von der Cmdline aufrufen...
Aus meiner fvwm-Konfiguration: + "Suspend to &Disk" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hibernate" + "Hybrid &Sleep" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Hybrid Sleep and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Suspend to &Ram" Exec ssh root@`hostname` "sync; systemctl suspend"; + "Suspend to Ram and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync; systemctl suspend" Ob das extra sync etwas bringt, weiß ich nicht, vermutlich macht systemd das ohnehin selber. Mein System ist verschlüsselt, deshalb gibt es bei "Suspend to disk" keinen Menüpunkt mit Screensaver Lock. 'ssh root...' läuft mit Public Key und beim Login am Display Manager eingegebener Passphrase. Darüber, wie lange die SSD aushält, mache ich mir Gedanken, wenn sie stirbt. Im Moment ist sie erst zwei Monate in Betrieb. Auf das gegenüber vorher ungleich flottere Suspend to Disk mag ich nicht verzichten. -- Viele Grüße Michael
Am 16.06.21 um 13:47 schrieb Michael Behrens:
Am 16.06.21 um 07:50 schrieb Jörg Thümmler:
... 2. das ganze von der Cmdline aufrufen...
Aus meiner fvwm-Konfiguration:
+ "Suspend to &Disk" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hibernate" + "Hybrid &Sleep" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Hybrid Sleep and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Suspend to &Ram" Exec ssh root@`hostname` "sync; systemctl suspend"; + "Suspend to Ram and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync; systemctl suspend"
Ob das extra sync etwas bringt, weiß ich nicht, vermutlich macht systemd das ohnehin selber. Mein System ist verschlüsselt, deshalb gibt es bei "Suspend to disk" keinen Menüpunkt mit Screensaver Lock. 'ssh root...' läuft mit Public Key und beim Login am Display Manager eingegebener Passphrase.
Darüber, wie lange die SSD aushält, mache ich mir Gedanken, wenn sie stirbt. Im Moment ist sie erst zwei Monate in Betrieb. Auf das gegenüber vorher ungleich flottere Suspend to Disk mag ich nicht verzichten.
Hi, Danke, systemctl hibernate mit und ohne sync werde ich mal probieren, klingt gut. Unter https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibe... habe ich übrigens was gefunden, was sich mit dem Ort des Images befasst, danach scheint das einfach in der swap-Partition zu landen. Wenn dem so ist (werde mal versuchen, das mittels Verlegen des Swaps auf eine externe Karte zu testen) könnte man ja einfach generell den Swap, der mir bei der SSD auch schon ein Dorn im Auge ist, dahin zu verlegen, dann hat man das weg. Das Lesen und Schreiben auf eine SD-Karte geht sicher ein wenig langsamer, als auf eine SSD und die Karte geht sicher schneller kaputt... aber sie kostet weniger, als die SSD und es ist keine Freude, im eeePC die Disk zu wechseln... -- cu jth
Am 16.06.2021 um 16:06 schrieb Jörg Thümmler:
Am 16.06.21 um 13:47 schrieb Michael Behrens:
Am 16.06.21 um 07:50 schrieb Jörg Thümmler:
... 2. das ganze von der Cmdline aufrufen...
Aus meiner fvwm-Konfiguration:
+ "Suspend to &Disk" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hibernate" + "Hybrid &Sleep" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Hybrid Sleep and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Suspend to &Ram" Exec ssh root@`hostname` "sync; systemctl suspend"; + "Suspend to Ram and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync; systemctl suspend"
Ob das extra sync etwas bringt, weiß ich nicht, vermutlich macht systemd das ohnehin selber. Mein System ist verschlüsselt, deshalb gibt es bei "Suspend to disk" keinen Menüpunkt mit Screensaver Lock. 'ssh root...' läuft mit Public Key und beim Login am Display Manager eingegebener Passphrase.
Darüber, wie lange die SSD aushält, mache ich mir Gedanken, wenn sie stirbt. Im Moment ist sie erst zwei Monate in Betrieb. Auf das gegenüber vorher ungleich flottere Suspend to Disk mag ich nicht verzichten.
Hi,
Danke, systemctl hibernate mit und ohne sync werde ich mal probieren, klingt gut.
Unter
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibe...
habe ich übrigens was gefunden, was sich mit dem Ort des Images befasst, danach scheint das einfach in der swap-Partition zu landen. Wenn dem so ist (werde mal versuchen, das mittels Verlegen des Swaps auf eine externe Karte zu testen) könnte man ja einfach generell den Swap, der mir bei der SSD auch schon ein Dorn im Auge ist, dahin zu verlegen, dann hat man das weg. Das Lesen und Schreiben auf eine SD-Karte geht sicher ein wenig langsamer, als auf eine SSD und die Karte geht sicher schneller kaputt... aber sie kostet weniger, als die SSD und es ist keine Freude, im eeePC die Disk zu wechseln...
Also den Swap auf eine SD-Karte zu legen halte ich für mit die dümmste Idee aller dummen Ideen auf diesem Gebiet. Ich weiß ja nicht was für eine Schrott-SSD du da eingebaut hast, aber ich denke das schaffst du im Leben nicht die SSD dadurch in die Knie zu zwingen. Und falls du es noch nicht wissen solltest, die meisten SD-Cards gehen durch Power-off zum falschen Zeitpunkt kaputt. Und das scheint mir exakt so ein Anwendungsfall dafür zu sein. Manfred
Am 16.06.21 um 22:00 schrieb Manfred Kreisl:
Am 16.06.2021 um 16:06 schrieb Jörg Thümmler:
Am 16.06.21 um 13:47 schrieb Michael Behrens:
Am 16.06.21 um 07:50 schrieb Jörg Thümmler: >...
2. das ganze von der Cmdline aufrufen...
Aus meiner fvwm-Konfiguration:
+ "Suspend to &Disk" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hibernate" + "Hybrid &Sleep" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Hybrid Sleep and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Suspend to &Ram" Exec ssh root@`hostname` "sync; systemctl suspend"; + "Suspend to Ram and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync; systemctl suspend"
Ob das extra sync etwas bringt, weiß ich nicht, vermutlich macht systemd das ohnehin selber. Mein System ist verschlüsselt, deshalb gibt es bei "Suspend to disk" keinen Menüpunkt mit Screensaver Lock. 'ssh root...' läuft mit Public Key und beim Login am Display Manager eingegebener Passphrase.
Darüber, wie lange die SSD aushält, mache ich mir Gedanken, wenn sie stirbt. Im Moment ist sie erst zwei Monate in Betrieb. Auf das gegenüber vorher ungleich flottere Suspend to Disk mag ich nicht verzichten.
Hi,
Danke, systemctl hibernate mit und ohne sync werde ich mal probieren, klingt gut.
Unter
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibe...
habe ich übrigens was gefunden, was sich mit dem Ort des Images befasst, danach scheint das einfach in der swap-Partition zu landen. Wenn dem so ist (werde mal versuchen, das mittels Verlegen des Swaps auf eine externe Karte zu testen) könnte man ja einfach generell den Swap, der mir bei der SSD auch schon ein Dorn im Auge ist, dahin zu verlegen, dann hat man das weg. Das Lesen und Schreiben auf eine SD-Karte geht sicher ein wenig langsamer, als auf eine SSD und die Karte geht sicher schneller kaputt... aber sie kostet weniger, als die SSD und es ist keine Freude, im eeePC die Disk zu wechseln...
Also den Swap auf eine SD-Karte zu legen halte ich für mit die dümmste Idee aller dummen Ideen auf diesem Gebiet.
Ich weiß ja nicht was für eine Schrott-SSD du da eingebaut hast, aber ich denke das schaffst du im Leben nicht die SSD dadurch in die Knie zu zwingen.
Und falls du es noch nicht wissen solltest, die meisten SD-Cards gehen durch Power-off zum falschen Zeitpunkt kaputt. Und das scheint mir exakt so ein Anwendungsfall dafür zu sein.
Manfred
Hi und Danke für Deinen Hinweis, ich denke nicht, dass die SSD "Schrott" ist, habe aber auch noch keine kaputte SD-Card gehabt. Power off zum "falschen Zeitpunkt" wird dabei nicht ausgeblieben sein... zumal ich nicht ganz sehe, was am Hibernate ein "falscher Zeitpunkt" sein soll. Ich hab mir mal den systemd-service angesehen, offensichtlich wird nach dem Speichern des Abzugs ganz normal poweroff gemacht und nur ein Marker fürs Booten hinterlassen, damit beim nächsten Mal der Abzug in den RAM geladen wird. Zu SSD findet man im Netz immer noch die verschiedensten Warnungen, um sie vorm vorzeitigen Tod zu schützen, kann schon sein, das aktuelle Teile da mehr aushalten... -- cu jth
Am 17.06.21 um 07:33 schrieb Jörg Thümmler:
... ich denke nicht, dass die SSD "Schrott" ist, habe aber auch noch keine kaputte SD-Card gehabt. Power off zum "falschen Zeitpunkt" wird dabei nicht ausgeblieben sein... zumal ich nicht ganz sehe, was am Hibernate ein "falscher Zeitpunkt" sein soll. Ich hab mir mal den systemd-service angesehen, offensichtlich wird nach dem Speichern des Abzugs ganz normal poweroff gemacht und nur ein Marker fürs Booten hinterlassen, damit beim nächsten Mal der Abzug in den RAM geladen wird.
Zu SSD findet man im Netz immer noch die verschiedensten Warnungen, um sie vorm vorzeitigen Tod zu schützen, kann schon sein, das aktuelle Teile da mehr aushalten...
In Netz findet man viel, unterm Strich, aus meinen Archiv, aus 2016, etwas zum Firefox. Peter ------------------------ *Hat der Fuchs schon einige SSDs auf dem Gewissen? mozilla.org *Die Sicherung der gerade geöffneten Fenster sorgt für viel Schreiblast. Mit wenigen Klicks lässt sich diese reduzieren. Die IT-Webseite Servethehome warnt davor, dass der Browser Firefox im Rechner oder Notebook verbaute SSDs über kurz oder lang auffressen würde Nach Beobachtungen des Autors wurden täglich bis zu 35 GB auf den Datenträger geschrieben. Der Grund dafür findet sich in einer Backup-Funktion von Firefox, die beim einem Absturz geöffnete Fenster wieder herstellen kann. In der Standardeinstellung passiert dies alle 15 bis 30 Sekunden. Auch der Internet Explorer oder Googles Browser Chrome haben eine ähnliche Funktion. Entsprechend werden auch hier viele Daten auf der System-Platte oder -SSD zwischengespeichert. Laut Spiegel Online sei dies jedoch unbedenklich. Samsung erklärt, dass selbst günstige SSDs locker Schreibvorgänge von 41 GB pro Tag aushalten. Vorsichtige Anwender können den Umfang von Schreibvorgängen in Firefox trotzdem reduzieren. Dazu muss die Adresse „about:config“ eingegeben werden. In den dadurch angezeigten Einstellungen lässt sich anschließend nach „browser.sessionstore.interval“ suchen. Wird der Wert von 15 Sekunden (15.000) auf 30.000 erhöht, sichert Firefox nur alle 30 Sekunden die geöffneten Fenster und so weiter.
Am 17.06.21 um 09:34 schrieb Peter McD:
Am 17.06.21 um 07:33 schrieb Jörg Thümmler:
... ich denke nicht, dass die SSD "Schrott" ist, habe aber auch noch keine kaputte SD-Card gehabt. Power off zum "falschen Zeitpunkt" wird dabei nicht ausgeblieben sein... zumal ich nicht ganz sehe, was am Hibernate ein "falscher Zeitpunkt" sein soll. Ich hab mir mal den systemd-service angesehen, offensichtlich wird nach dem Speichern des Abzugs ganz normal poweroff gemacht und nur ein Marker fürs Booten hinterlassen, damit beim nächsten Mal der Abzug in den RAM geladen wird.
Zu SSD findet man im Netz immer noch die verschiedensten Warnungen, um sie vorm vorzeitigen Tod zu schützen, kann schon sein, das aktuelle Teile da mehr aushalten...
In Netz findet man viel, unterm Strich, aus meinen Archiv, aus 2016, etwas zum Firefox.
Peter
------------------------ *Hat der Fuchs schon einige SSDs auf dem Gewissen?
mozilla.org
*Die Sicherung der gerade geöffneten Fenster sorgt für viel Schreiblast. Mit wenigen Klicks lässt sich diese reduzieren.
Die IT-Webseite Servethehome warnt davor, dass der Browser Firefox im Rechner oder Notebook verbaute SSDs über kurz oder lang auffressen würde Nach Beobachtungen des Autors wurden täglich bis zu 35 GB auf den Datenträger geschrieben. Der Grund dafür findet sich in einer Backup-Funktion von Firefox, die beim einem Absturz geöffnete Fenster wieder herstellen kann. In der Standardeinstellung passiert dies alle 15 bis 30 Sekunden.
Auch der Internet Explorer oder Googles Browser Chrome haben eine ähnliche Funktion. Entsprechend werden auch hier viele Daten auf der System-Platte oder -SSD zwischengespeichert. Laut Spiegel Online sei dies jedoch unbedenklich. Samsung erklärt, dass selbst günstige SSDs locker Schreibvorgänge von 41 GB pro Tag aushalten.
Vorsichtige Anwender können den Umfang von Schreibvorgängen in Firefox trotzdem reduzieren. Dazu muss die Adresse „about:config“ eingegeben werden. In den dadurch angezeigten Einstellungen lässt sich anschließend nach „browser.sessionstore.interval“ suchen. Wird der Wert von 15 Sekunden (15.000) auf 30.000 erhöht, sichert Firefox nur alle 30 Sekunden die geöffneten Fenster und so weiter.
Hi, guter Tipp! Danke -- cu jth
Am 17.06.2021 um 07:33 schrieb Jörg Thümmler:
Am 16.06.21 um 22:00 schrieb Manfred Kreisl:
Am 16.06.2021 um 16:06 schrieb Jörg Thümmler:
Am 16.06.21 um 13:47 schrieb Michael Behrens:
Am 16.06.21 um 07:50 schrieb Jörg Thümmler:
... 2. das ganze von der Cmdline aufrufen...
Aus meiner fvwm-Konfiguration:
+ "Suspend to &Disk" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hibernate" + "Hybrid &Sleep" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Hybrid Sleep and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Suspend to &Ram" Exec ssh root@`hostname` "sync; systemctl suspend"; + "Suspend to Ram and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync; systemctl suspend"
Ob das extra sync etwas bringt, weiß ich nicht, vermutlich macht systemd das ohnehin selber. Mein System ist verschlüsselt, deshalb gibt es bei "Suspend to disk" keinen Menüpunkt mit Screensaver Lock. 'ssh root...' läuft mit Public Key und beim Login am Display Manager eingegebener Passphrase.
Darüber, wie lange die SSD aushält, mache ich mir Gedanken, wenn sie stirbt. Im Moment ist sie erst zwei Monate in Betrieb. Auf das gegenüber vorher ungleich flottere Suspend to Disk mag ich nicht verzichten.
Hi,
Danke, systemctl hibernate mit und ohne sync werde ich mal probieren, klingt gut.
Unter
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibe...
habe ich übrigens was gefunden, was sich mit dem Ort des Images befasst, danach scheint das einfach in der swap-Partition zu landen. Wenn dem so ist (werde mal versuchen, das mittels Verlegen des Swaps auf eine externe Karte zu testen) könnte man ja einfach generell den Swap, der mir bei der SSD auch schon ein Dorn im Auge ist, dahin zu verlegen, dann hat man das weg. Das Lesen und Schreiben auf eine SD-Karte geht sicher ein wenig langsamer, als auf eine SSD und die Karte geht sicher schneller kaputt... aber sie kostet weniger, als die SSD und es ist keine Freude, im eeePC die Disk zu wechseln...
Also den Swap auf eine SD-Karte zu legen halte ich für mit die dümmste Idee aller dummen Ideen auf diesem Gebiet.
Ich weiß ja nicht was für eine Schrott-SSD du da eingebaut hast, aber ich denke das schaffst du im Leben nicht die SSD dadurch in die Knie zu zwingen.
Und falls du es noch nicht wissen solltest, die meisten SD-Cards gehen durch Power-off zum falschen Zeitpunkt kaputt. Und das scheint mir exakt so ein Anwendungsfall dafür zu sein.
Manfred
Hi und Danke für Deinen Hinweis,
ich denke nicht, dass die SSD "Schrott" ist, habe aber auch noch keine kaputte SD-Card gehabt. Power off zum "falschen Zeitpunkt" wird dabei nicht ausgeblieben sein... zumal ich nicht ganz sehe, was am Hibernate ein "falscher Zeitpunkt" sein soll. Ich hab mir mal den systemd-service angesehen, offensichtlich wird nach dem Speichern des Abzugs ganz normal poweroff gemacht und nur ein Marker fürs Booten hinterlassen, damit beim nächsten Mal der Abzug in den RAM geladen wird.
Es geht nicht um SSD, sondern SD-Card. Und das System wird bestimmt nicht wissen ob und wann die SD-Card ihre internen Arbeiten erledigt hat und man der Karte den Strom abziehen kann. Und das ist der häufige Tod der SD-Karten dann halt (zumindest lt. c't)
Zu SSD findet man im Netz immer noch die verschiedensten Warnungen, um sie vorm vorzeitigen Tod zu schützen, kann schon sein, das aktuelle Teile da mehr aushalten...
Ja, alles alte vergammelte Ansichten die schon längst aus den Netz entfernt werden sollten Ebenso die Firefox Schauermärchen, genauso Vollkrampf. Bei meinem System mit einer Million offener Tabs in 4 Fenstern hab ich eine durchschnittliche Schreibleistung von 12GB/Tag (protokolliert über /proc/diskstat). Und das obwohl auch der Swap im SSD ist (war er lange Zeit auch nicht) Früher hab ich auch mangels Erfahrung auf solche Schauermärchen Rücksicht genommen und große Vorsicht walten lassen, aber mittlerweile bin ich zu der Überzeugung gekommen, dass das nur dummes Gelabere von halbwissenden Möchtegernbesserwissern ist Daher mein Tip: Vergiss das alles solange du nicht mit gigabyte großen Files herumhantierst (das wirst du dir auf dem eeepc eh nicht antun) und arbeite einfach damit Manfred
Am 17.06.21 um 13:20 schrieb Manfred Kreisl:
Am 17.06.2021 um 07:33 schrieb Jörg Thümmler:
Am 16.06.21 um 22:00 schrieb Manfred Kreisl:
Am 16.06.2021 um 16:06 schrieb Jörg Thümmler:
Am 16.06.21 um 13:47 schrieb Michael Behrens:
Am 16.06.21 um 07:50 schrieb Jörg Thümmler: >...
2. das ganze von der Cmdline aufrufen...
Aus meiner fvwm-Konfiguration:
+ "Suspend to &Disk" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hibernate" + "Hybrid &Sleep" Exec ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Hybrid Sleep and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync && sysctl vm.drop_caches=1; systemctl hybrid-sleep" + "Suspend to &Ram" Exec ssh root@`hostname` "sync; systemctl suspend"; + "Suspend to Ram and Lock" Exec mate-screensaver-command --lock & sleep 2; ssh root@`hostname` "sync; systemctl suspend"
Ob das extra sync etwas bringt, weiß ich nicht, vermutlich macht systemd das ohnehin selber. Mein System ist verschlüsselt, deshalb gibt es bei "Suspend to disk" keinen Menüpunkt mit Screensaver Lock. 'ssh root...' läuft mit Public Key und beim Login am Display Manager eingegebener Passphrase.
Darüber, wie lange die SSD aushält, mache ich mir Gedanken, wenn sie stirbt. Im Moment ist sie erst zwei Monate in Betrieb. Auf das gegenüber vorher ungleich flottere Suspend to Disk mag ich nicht verzichten.
Hi,
Danke, systemctl hibernate mit und ohne sync werde ich mal probieren, klingt gut.
Unter
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate#Hibe...
habe ich übrigens was gefunden, was sich mit dem Ort des Images befasst, danach scheint das einfach in der swap-Partition zu landen. Wenn dem so ist (werde mal versuchen, das mittels Verlegen des Swaps auf eine externe Karte zu testen) könnte man ja einfach generell den Swap, der mir bei der SSD auch schon ein Dorn im Auge ist, dahin zu verlegen, dann hat man das weg. Das Lesen und Schreiben auf eine SD-Karte geht sicher ein wenig langsamer, als auf eine SSD und die Karte geht sicher schneller kaputt... aber sie kostet weniger, als die SSD und es ist keine Freude, im eeePC die Disk zu wechseln...
Also den Swap auf eine SD-Karte zu legen halte ich für mit die dümmste Idee aller dummen Ideen auf diesem Gebiet.
Ich weiß ja nicht was für eine Schrott-SSD du da eingebaut hast, aber ich denke das schaffst du im Leben nicht die SSD dadurch in die Knie zu zwingen.
Und falls du es noch nicht wissen solltest, die meisten SD-Cards gehen durch Power-off zum falschen Zeitpunkt kaputt. Und das scheint mir exakt so ein Anwendungsfall dafür zu sein.
Manfred
Hi und Danke für Deinen Hinweis,
ich denke nicht, dass die SSD "Schrott" ist, habe aber auch noch keine kaputte SD-Card gehabt. Power off zum "falschen Zeitpunkt" wird dabei nicht ausgeblieben sein... zumal ich nicht ganz sehe, was am Hibernate ein "falscher Zeitpunkt" sein soll. Ich hab mir mal den systemd-service angesehen, offensichtlich wird nach dem Speichern des Abzugs ganz normal poweroff gemacht und nur ein Marker fürs Booten hinterlassen, damit beim nächsten Mal der Abzug in den RAM geladen wird.
Es geht nicht um SSD, sondern SD-Card. Und das System wird bestimmt nicht wissen ob und wann die SD-Card ihre internen Arbeiten erledigt hat und man der Karte den Strom abziehen kann. Und das ist der häufige Tod der SD-Karten dann halt (zumindest lt. c't)
Zu SSD findet man im Netz immer noch die verschiedensten Warnungen, um sie vorm vorzeitigen Tod zu schützen, kann schon sein, das aktuelle Teile da mehr aushalten...
Ja, alles alte vergammelte Ansichten die schon längst aus den Netz entfernt werden sollten
Ebenso die Firefox Schauermärchen, genauso Vollkrampf. Bei meinem System mit einer Million offener Tabs in 4 Fenstern hab ich eine durchschnittliche Schreibleistung von 12GB/Tag (protokolliert über /proc/diskstat). Und das obwohl auch der Swap im SSD ist (war er lange Zeit auch nicht)
Früher hab ich auch mangels Erfahrung auf solche Schauermärchen Rücksicht genommen und große Vorsicht walten lassen, aber mittlerweile bin ich zu der Überzeugung gekommen, dass das nur dummes Gelabere von halbwissenden Möchtegernbesserwissern ist
Daher mein Tip: Vergiss das alles solange du nicht mit gigabyte großen Files herumhantierst (das wirst du dir auf dem eeepc eh nicht antun) und arbeite einfach damit
Manfred
Hi, OK, ich werde das mal laufenlassen. Die paar Dinge, die zu verlieren schmerzlich wäre, landen ohnehin im Backup. Danke an alle -- cu jth
participants (4)
-
Jörg Thümmler -
Manfred Kreisl -
Michael Behrens -
Peter McD