Neue Testversion (3.51.6.20200509) mit AstroTimer-Offsets verfügbar

[jmaus]

Kein Wunder, fstrim schrubbt auf der SD wie wild rum. Damit Blöcke als verfügbar gekennzeichnet werden können müssen ja auch Schreiboperationen getätigt werden. Das killt auf Dauer eine SD zuverlässig.

Wo hast du diese Information her? Meines Wissens "schrubbt" da nichts auf der SD karte rum, sondern die Blöcke die eigentlich bereits freigegeben sind werden nur als solche noch einmal genauer markiert. Genau deshalb habe ich ja auch vorgesehen einen fstrim cronjob mit der nächsten kommenden Version direkt in RaspberryMatic integriert zu haben.

[Xel66]

Ich weiß selbst, dass diese Formulierung bescheiden ist, aber "ich habe es küzlich irgendwo gelesen", dass man fstrim gerade bei nicht so hochqualitativen SSD lieber nicht wegen der "begrenzten" Anzahl der Schreibzugriffe einsetzen soll, weil diese "Markierungsvorgänge" von freien Speicherblöcken eben Schreibzugriffe auf den Datenträger verursachen (EDIT: zumindest ein Mal auf die Schnelle gefunden, habe es aber mehrfach gelesen). Hat man nun nicht gerade eine industrielle SD in seinem System (normale SDs haben gegenüber SSDs noch weniger Standvermögen bezüglich der Schreibzugriffe), dann treibt dieses die Anzahl der Zugriffe hoch und irgendwann sind die Zellen kaputt, die das Filesystem verwalten, und die SD ist defekt. In meinem System würde ich diesen cron-Job rausschmeißen und lieber mit der etwas geringeren Zugriffsgeschwindigkeit leben, die sich ja größtenteil sowieso nur auf den Systemstart auswirkt.

Gruß Xel66

[deimos]

Hi,

fstrim bei SD Karten macht keinen Sinn, da diese kein Wearleveling unterstützen. Durch fstrim treibt man da nur Schreibzyklen pro Zelle hoch.
Genauso wenig macht fstrim bei Festplatten mit Spindel Sinn, hier macht esnichts kaputt, aber kostet unnötig IO.

Sinn macht fstrim nur bei Laufwerken, welche Discard unterstützen, also SSDs und Thin Provisioned Virtual Discs, sofern das Virtualisierungssystem das unterstützt und die Funktion auch aktiviert ist.

Viele Grüße
Alex

[jmaus]

fstrim bei SD Karten macht keinen Sinn, da diese kein Wearleveling unterstützen. Durch fstrim treibt man da nur Schreibzyklen pro Zelle hoch.

Bist du dir da sicher? Hast du dazu irgendwelche Referenzen/Links? Das SD Karten kein Wearleveling machen/haben ist ja klar. Aber meinen Recherchen und Tests nach macht fstrim selbst ja tests und prüft ob TRIM als Kommando überhaupt vom angewendeten Medium unterstützt wird oder nicht. Und im Netz habe ich keine Stellen gefunden wo negativ darüber berichtet wird fstrim als cronjob auch bei einem RaspberryPi mit nur SD Katte einzurichten. Und weil vorher ja fstrim prüft ob das TRIM oder ähnliche Kommandos vom darunterliegenden Controller unterstützt wird bin ich davon ausgegangen das es kein Problem sein sollte das generell zu aktivieren.

Sinn macht fstrim nur bei Laufwerken, welche Discard unterstützen, also SSDs und Thin Provisioned Virtual Discs, sofern das Virtualisierungssystem das unterstützt und die Funktion auch aktiviert ist.

Und genau für diese Thin Provisioned VM Disks habe ich das fstrim aufgenommen und bin bis jetzt immer noch der Meinung das es doch selbst herausfindet ob ein gemountetes Medium bzw der Controller das notwendig TRIM/Discard Kommando unterstützt oder nicht und wenn es problematisch wäre das einzusetzen, dann würde doch der SD Karten Controller bzw Treiber das doch nicht unterstützen. Oder nicht?

[deimos]

Hi,

fstrim bei SD Karten macht keinen Sinn, da diese kein Wearleveling unterstützen. Durch fstrim treibt man da nur Schreibzyklen pro Zelle hoch.

Bist du dir da sicher? Hast du dazu irgendwelche Referenzen/Links? Das SD Karten kein Wearleveling machen/haben ist ja klar. Aber meinen Recherchen und Tests nach macht fstrim selbst ja tests und prüft ob TRIM als Kommando überhaupt vom angewendeten Medium unterstützt wird oder nicht. Und im Netz habe ich keine Stellen gefunden wo negativ darüber berichtet wird fstrim als cronjob auch bei einem RaspberryPi mit nur SD Katte einzurichten. Und weil vorher ja fstrim prüft ob das TRIM oder ähnliche Kommandos vom darunterliegenden Controller unterstützt wird bin ich davon ausgegangen das es kein Problem sein sollte das generell zu aktivieren.

Alles, was ich an Doku kenne, spricht davon, das geprüft wird, ob das Filesystem das unterstützt und nicht davon, ob das Device das unterstützt.

Bei einem schnellen Test auf auf einen Raspberry Pi 4 mit Standard Raspbian hat er mir grade munter auf der SD Karte Daten getrimmt mit etlichen IOs.

Viele Grüße
Alex

[jmaus]

fstrim bei SD Karten macht keinen Sinn, da diese kein Wearleveling unterstützen. Durch fstrim treibt man da nur Schreibzyklen pro Zelle hoch.

Bist du dir da sicher? Hast du dazu irgendwelche Referenzen/Links? Das SD Karten kein Wearleveling machen/haben ist ja klar. Aber meinen Recherchen und Tests nach macht fstrim selbst ja tests und prüft ob TRIM als Kommando überhaupt vom angewendeten Medium unterstützt wird oder nicht. Und im Netz habe ich keine Stellen gefunden wo negativ darüber berichtet wird fstrim als cronjob auch bei einem RaspberryPi mit nur SD Katte einzurichten. Und weil vorher ja fstrim prüft ob das TRIM oder ähnliche Kommandos vom darunterliegenden Controller unterstützt wird bin ich davon ausgegangen das es kein Problem sein sollte das generell zu aktivieren.

Alles, was ich an Doku kenne, spricht davon, das geprüft wird, ob das Filesystem das unterstützt und nicht davon, ob das Device das unterstützt.

Ok. Ich hab aber schon Systeme beim test gehabt die alle mit ext4 genutzt wurden, dann aber beim fstrim einmal gesagt hatten das die operation nicht unterstützt wäre und bei anderen nicht. Also scheint da in der Tat etwas an den Controller weitergeleitet zu werden und wenn dieser das TRIM/DISCARD kommando nicht hat scheint fstrim das mitzubekommen.

Bei einem schnellen Test auf auf einen Raspberry Pi 4 mit Standard Raspbian hat er mir grade munter auf der SD Karte Daten getrimmt mit etlichen IOs.

Ich hab leider gerade keinen RaspberryPi zur Hand, aber mit folgender Prozedur könntest du schauen ob das trimming auf der SD Karte wirklich umgesetzt wird oder nicht:

https://unix.stackexchange.com/question ... 5880#85880

Auf einem Tinkerboard habe ich das gerade getestet und dort läuft zwar das fstrim kommando durch, aber auf der eMMC passiert nichts, d.h. das "yes" pattern ist da immer noch zu sehen auch nach dem fstrim. Und das lässt darauf schliessen das die eMMC des Tinkerboard das TRIM nicht korrekt unterstützt, fstrim aber davon ausgeht das es geht und daher I/O passiert.

[sissiwup]

Hallo,

wenn schon Astro-Timer-Offsets eingebaut werden,
dann sollte man auch komplett abdecken.

Was braucht man:

30 Minuten vor Sonnenaufgang, aber nicht vor 7:00 Uhr
und Abends
30 Minuten nach Sonnenuntergang, aber nicht nach 22:00 Uhr

Optimal wäre natürlich noch die bürgerliche Dämmerung.

Ich glaube das Thema Astro-Timer wird schon durch so viele Skripte
hervorragend gelöst, das es hier nur zur Verwirrung von Einsteigern führt.

Ich persönlich verwende keine Timer der CCU, sondern nur welche von CUXD.
Die laufen zu 99,9% zuverlässig.

[Xel66]

dann sollte man auch komplett abdecken.

Kann man ganz einfach durch die Kombination zweier verUNDeter Zeitmodule abdecken. Alles in einem geht nun mal nicht, weil es die Firmware wohl nicht zulässt. Außerdem ist es nachvollziehbar. Eines für die Astrosteuerung und eines für die Uhrzeit. Also im Grunde, wie es bisher auch gehandhabt wurde, nur dass man eben jetzt einen Schaltzeitpunkt vor dem jeweiligen Ereignis definieren kann. Für solche Anforderungen muss man nicht gleich die ganze GUI umstricken um eine zusätzliche Option hinzuzufügen.

Ich glaube das Thema Astro-Timer wird schon durch so viele Skripte
hervorragend gelöst...

Naja, ein zyklischer Aufruf eines Scriptes alle paar Minuten 24/7 um einige wenige Schaltpunkte am Tag rund um den Sonnenauf- oder -untergang zu definieren, ist für mich alles andere, nur nicht hervorragend. Für einen gradgenauen Trigger muss das Script mindestens alle fünf Minuten laufen. Macht mindestens 288 Scriptläufe um wieviel Schaltpunkte pro Tag zu triggern? Und die Anwender sind schon mit diesen Lösungen teils massiv überfordert. Ein Zeitmodul ist recht einfach zu bedienen und selbst da kommt es immer wieder zu Missverständnissen, weil vom Hersteller zur Verfügung gestellte Anleitungen lesen ist nicht die Stärke des modernen Anwenders (dabei sind es im WebUI-Handbuch nur ganze fünf Seiten für das Zeitmodul in denen alle Optionen erklärt sind). Der schaut sich lieber YT-Videos an, ist aber nicht mal in der Lage, die zur Verfügung stehenden Optionen durchzuklicken (man könnte wohl was kaputt machen).

Ich persönlich verwende keine Timer der CCU, sondern nur welche von CUXD.

Verwende ich auch für diverse Zwecke. Und für normale Uhrzeiten und Kalendertage tut es das on bord-Zeitmodul allemal. Es hat halt jede Lösung ihren eigenen Charme und Anwendungszweck. Die laufenden Verzögerungen haben z.B. einen gravierenden Nachteil. Sie überleben keinen Reboot der CCU. Die CUxD-Timer schon. Und für Uhrzeittrigger tut das Zeitmodul zuverlässig und intuitiv seinen Dienst.

Gruß Xel66

[Black]

muss man nicht, man kann zeitmodule auch mit dynamischen schaltpunkten laden....

Black

[Xel66]

... dynamischen schaltpunkten laden...

Ich weiß, aber eben nicht per WebUI direkt. Mit SDV ist vieles möglich.

Gruß Xel66