Cronjob /sbin/fstrim macht ärger.

[ejdv]

Hallo,

Dachte es ist vielleicht besser dieses Thema als neues Thema zu erstellen.
Will dieses Thema nicht 'zumüllen':
viewtopic.php?f=65&t=58684
Neue Testversion (3.51.6.20200509) mit AstroTimer-Offsets verfügbar

Also, seit 3.51.6.20200509 habe ich Probleme mit dem Web UI und konnte meinen Raspberry Pi 3 Model B+ per SSH nicht mehr erreichen.
Web UI zeigte "Eine Komponente der Homematic Zentrale reagiert nicht mehr.".
Einloggen mittel SSH ging nicht mehr.
Ping zum Gerät ging noch.

Nächsten Tag passierte wieder das gleiche.
Ich hatte aber einen SSH Session offen gehalten.
Leider konnte ich keine Kommandos absetzen:

Code: Alles auswählen

@raspimatic:/root# ls
-sh: ls: Input/output error

Ich habe dann rausfinden können, das die beide 'Crashes' nach 01:00 Uhr stattfanden (mittels einen Skript auf einen anderer RaspberryPi).

Im cron wird dann das hier ausgeführt:

Code: Alles auswählen

0 1 * * * /bin/nice /sbin/fstrim --all --quiet >/dev/null 2>/dev/null

"fstrim - discard unused blocks on a mounted filesystem"

Und schau, es macht wirklich ärger:

Code: Alles auswählen

root@raspimatic:~# /bin/nice /sbin/fstrim --all
fstrim: /usr/local: FITRIM ioctl failed: Input/output error
@raspimatic:/root# echo $?
32

@raspimatic:/root# ls
-sh: ls: Input/output error

Jede menge von Fehlermeldungen mit dmesg (nur Teil der Output):

Code: Alles auswählen

# dmesg --color=always --ctime --follow
:
:
Thu May 14 18:00:10 2020] mmc0: card never left busy state
[Thu May 14 18:00:10 2020] mmc0: error -110 whilst initialising SD card
[Thu May 14 18:00:11 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #625: comm udevd: reading directory lblock 0
[Thu May 14 18:00:11 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #821: comm udevd: reading directory lblock 0
[Thu May 14 18:00:11 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #821: comm udevd: reading directory lblock 0
[Thu May 14 18:00:13 2020] mmc0: card never left busy state
[Thu May 14 18:00:13 2020] mmc0: error -110 whilst initialising SD card
[Thu May 14 18:00:13 2020] EXT4-fs error: 4 callbacks suppressed
[Thu May 14 18:00:13 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #148: comm hss_led: reading directory lblock 0
[Thu May 14 18:00:13 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #148: comm hss_led: reading directory lblock 0
[Thu May 14 18:00:13 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #2: comm lighttpd: reading directory lblock 0
[Thu May 14 18:00:13 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #148: comm lighttpd: reading directory lblock 0
[Thu May 14 18:00:13 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #2: comm lighttpd: reading directory lblock 0
[Thu May 14 18:00:14 2020] mmc0: card never left busy state
[Thu May 14 18:00:14 2020] mmc0: error -110 whilst initialising SD card
[Thu May 14 18:00:15 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #2: comm ReGaHss: reading directory lblock 0
[Thu May 14 18:00:15 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #2: comm ReGaHss: reading directory lblock 0
[Thu May 14 18:00:15 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #3220: comm monit: reading directory lblock 0
[Thu May 14 18:00:15 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #13: comm monit: reading directory lblock 0
[Thu May 14 18:00:15 2020] EXT4-fs error (device mmcblk0p2): ext4_find_entry:1456: inode #3220: comm monit: reading directory lblock 0

Scheinbar gibt es diesen Cronjob erst seit 3.51.6.20200509.

Man sollte mit hdparm rausfinden können ob es unterstützt wird

Code: Alles auswählen

root@raspimatic:/sys/devices/platform/soc/3f202000.mmc/mmc_host/mmc0/mmc0:0001# hdparm -I /dev/mmcblk0p1
/dev/mmcblk0p1:
hdparm: HDIO_DRIVE_CMD: Invalid argument

So etwas sollte zurückkommen:

Code: Alles auswählen

Data Set Management TRIM supported

Oder halt nichts.

Was mich stört, ist das ich als Fehler den device mmcblk0p2 angezeigt bekomme, und die gibt es zwar, aber nicht als gemounted:

Code: Alles auswählen

root@raspimatic:~# mount | grep mmcblk0
/dev/mmcblk0p3 on /usr/local type ext4 (rw,noatime,nodiratime,nodelalloc,data=journal)
/dev/mmcblk0p1 on /boot type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

root@raspimatic:~# ll /dev/mmcblk0p*
brw-rw----    1 root     disk      179,   1 May 14 18:17 /dev/mmcblk0p1
brw-rw----    1 root     disk      179,   2 May 14 18:17 /dev/mmcblk0p2
brw-rw----    1 root     disk      179,   3 May 14 18:17 /dev/mmcblk0p3

Als Partition ist er da:

Code: Alles auswählen

root@raspimatic:~#parted --script /dev/mmcblk0p2 print
Model: Unknown (unknown)
Disk /dev/mmcblk0p2: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:
Number  Start  End     Size    File system  Flags
 1      0.00B  1074MB  1074MB  ext4

Vielleicht doch erschossen worden und bleibt mir nichts übrig als neu aufsetzen.
Obwohl alles scheinbar noch funktioniert, die neue Astro-Settings haben soeben meine Rollladen geschlossen
Für jetzt lasse ich es so laufen, mit dem fstrim Cronjob deaktiviert.

MfG,

ejdv

[jmaus]

Nach den Fehlern die du hier zeigst solltest du definitiv die SD Karte wechseln (und das so schnell wie möglich) egal ob der neue "fstrim" cronjob aktiviert ist oder nicht. Und meines Erachtens hat auch nicht das fstrim kommando deine SD Karte "gekillt" sondern umgedreht wird ein Schuh draus: Das fstrim kommando ist auf defekte SD Kartenblöcke gestoßen und hat die Probleme getriggert die du nun wahrgenommen hast.

[ejdv]

Und meines Erachtens hat auch nicht das fstrim kommando deine SD Karte "gekillt" sondern umgedreht wird ein Schuh draus: Das fstrim kommando ist auf defekte SD Kartenblöcke gestoßen und hat die Probleme getriggert die du nun wahrgenommen hast.

Das kann gut sein, aber dann hätte ich lieber eine Warnung und nicht ein Versuch mein System automatisch zu 'retten'.
Wenn ich Herzprobleme habe, werde ich auch nicht gleich versuchen einen Marathon zu laufen um fit zu werden.
Kann sehr gut sein das meine SD Karte auf seinem letzten Bein geht, aber auch mit ein Bein kann man noch weit kommen

Fast alle Kommandos dieser Art werden zu erst prüfen, Probleme melden bspw. die anstehende Änderungen zeigen und dann Aussteigen oder erst nach eine Abfrage weiter machen (oder mit eine Switch wie -r honorieren).

Verstehe mich nicht falsch, ich finde Sachen wie badblocks und fstrim noblen Dingen und finde es gut das du dir solchen Sachen überlegst, aber es sollte nicht mein system zerlegen ohne meine Zustimmung.
Ich hätte lieber eine Service Meldung bekommen mit "du solltest definitiv die SD Karte wechseln (und das so schnell wie möglich)" damit ich ein wenig Zeit bekomme einzugreifen.

MfG,

ejdv

[jmaus]

Ich hätte lieber eine Service Meldung bekommen mit "du solltest definitiv die SD Karte wechseln (und das so schnell wie möglich)" damit ich ein wenig Zeit bekomme einzugreifen.

So läuft das aber nicht. fstrim/badblocks kann eben nicht in die Zukunft blicken. Und wenn die SD Karte eben defekt ist oder nur ein schreibzyklus vor dem defekt ist kann badblocks das auch nicht aufdecken und fstrim löst dann nur etwas aus was ohnehin dann in kurzer zeit auch ohne fstrim passiert wäre. Da hilft nur ordentliches Geld in die Hand zu nehmen und nicht bei der SD kartenwahl zu sparen oder einfach ganz Abstand von der SD kartennutzung zu nehmen, die CCU/RaspberryMatic auf eMMC, USB Stick, SSD oder ähnliches zu betreiben oder gleich zu virtualisieren.

[ejdv]

Finde gerade diese Option:

Code: Alles auswählen

-n, --dry-run
              This option does everything apart from actually call FITRIM ioctl.

Denke aber es wird nichts anzeigen was auf Probleme deutet.

Nicht das es bei mir aussagekräftig ist, aber trotzdem:

Code: Alles auswählen

root@raspimatic:~# /sbin/fstrim --all --verbose --dry-run
/usr/local: 0 B (dry run) trimmed on /dev/mmcblk0p3

RaspberryPi 3 Model 3 mit SD Karte aus April 2016 (Raspbian GNU/Linux 10 (buster)):

Code: Alles auswählen

pi@raspberrypi:~ $ sudo /sbin/fstrim --all --verbose --dry-run
/boot: 0 B (dry run) trimmed on /dev/mmcblk0p1
/: 0 B (dry run) trimmed on /dev/mmcblk0p2

pi@raspberrypi:~ $ sudo /sbin/fstrim --all --verbose
/boot: 197.3 MiB (206846464 bytes) trimmed on /dev/mmcblk0p1
/: 4.6 GiB (4935573504 bytes) trimmed on /dev/mmcblk0p2

Glücklicherweise keine Probleme wie auf meinem Raspimatic (was keine Aussage zum RaspberryMatic SW ist, nur Feststellung).

Fazit: --dry-run bringt nichts, ausser falsche (?) Aussage.

[ejdv]

Da hilft nur ordentliches Geld in die Hand zu nehmen und nicht bei der SD kartenwahl zu sparen oder einfach ganz Abstand von der SD kartennutzung zu nehmen, die CCU/RaspberryMatic auf eMMC, USB Stick, SSD oder ähnliches zu betreiben oder gleich zu virtualisieren.

Beruhe es fast gepostet zu haben und Meldung dieses Problem gemacht zu haben, aber es sei so.
Ich habe nicht gespart beim SD Kartenwahl, SanDisk Ultra noch was Karte, kein No-Name; ist aber egal.

Auf einem anderen Medium umsteigen ist aber eine gute Hinweis.

[jmaus]

Da hilft nur ordentliches Geld in die Hand zu nehmen und nicht bei der SD kartenwahl zu sparen oder einfach ganz Abstand von der SD kartennutzung zu nehmen, die CCU/RaspberryMatic auf eMMC, USB Stick, SSD oder ähnliches zu betreiben oder gleich zu virtualisieren.

Beruhe es fast gepostet zu haben und Meldung dieses Problem gemacht zu haben, aber es sei so.

Das musst bzw. solltest du nicht bereuen, dafür bin ich in der Tat dankbar. Allerdings sind meiner Meinung nach deine Implikationen nicht ganz komplett durchdacht. fstrim ist ja nicht dafür da fehler aufzudecken, sondern dafür eine größere defragmentierung des genutzten Medium (in deinem Falle eben eine SD Karte) über einen längeren zeitraum zu vermeiden. Insofern ergibt die Nutzung von --dry-run in der Tat nicht soviel Sinn. Und ich bezweifle einfach weiterhin das es zwischen der Nutzung von fstrim und dem Ausfall bzw. dem korrupten Dateisystem auf deiner SD Karte einen Zusammenhang gibt der darauf schließen lässt das fstrim prinzipiell vermieden werden sollte in Kombination mit der Nutzung einer SD Karte. Als ich das Feature im aktuellen Snapshot von RaspberryMatic integriert habe, habe ich natürlich sehr wohl nach irgendwelchen bekannten Problemen im Zusammenhang mit fstrim und der Nutzung mit einer SD karte recherchiert. Bis dato bin ich jedoch auf keine mir kausal zusammenhängenden Problemberichte gestoßen und genau deshalb habe ich den fstrim cronjob mit als standard cronjob für die nächste Version aufgenommen.

In deinem Fall halte ich es einfach für wesentlich wahrscheinlicher, das deine SD karte einfach vorher bereits ein Problem hatte das sich auch ggf. an anderer bzw. späterer Stelle manifestiert hat/hätte. fstrim war/ist da IMHO nur der Auslöser um das Problem sichtbar zu machen und nicht der Schuldige. Es erscheint mir also etwas zu kurz gedacht einfach aus der Tatsache heraus das nach dem Aufruf von fstrim deine SD Karte probleme zeigt/zeigte darauf zu schliessen das fstrim hier wohl generell vermieden werden sollte.

Was du aber definitiv machen solltest ist die SD Karte zu ersetzen. Keine Minute würde ich bei den von dir gezeigten Fehlermeldungen weiter mit dieser SD Karte arbeiten.

[ejdv]

Allerdings sind meiner Meinung nach deine Implikationen nicht ganz komplett durchdacht. fstrim ist ja nicht dafür da fehler aufzudecken, sondern dafür eine größere defragmentierung des genutzten Medium (in deinem Falle eben eine SD Karte) über einen längeren zeitraum zu vermeiden. Insofern ergibt die Nutzung von --dry-run in der Tat nicht soviel Sinn. Und ich bezweifle einfach weiterhin das es zwischen der Nutzung von fstrim und dem Ausfall bzw. dem korrupten Dateisystem auf deiner SD Karte einen Zusammenhang gibt der darauf schließen lässt das fstrim prinzipiell vermieden werden sollte in Kombination mit der Nutzung einer SD Karte. Als ich das Feature im aktuellen Snapshot von RaspberryMatic integriert habe, habe ich natürlich sehr wohl nach irgendwelchen bekannten Problemen im Zusammenhang mit fstrim und der Nutzung mit einer SD karte recherchiert. Bis dato bin ich jedoch auf keine mir kausal zusammenhängenden Problemberichte gestoßen und genau deshalb habe ich den fstrim cronjob mit als standard cronjob für die nächste Version aufgenommen.

Danke für die ausführliche Antwort.

Es ist mir klar, das man keine vorstehende Fehler aufdecken kann, eine Speicherzelle wird dir nicht sagen "noch ein mal und ich gehe kaputt".
Aber anscheinend ist gerade fstrim etwas was unerwünschte Fehler verursachen kann bei SD Karten.
Habe verschiedene Artikel darüber finden können.
Und es wird empfohlen es wöchentlich zu machen (siehe zB ubuntu fstrim man page).

Ich bin auf deine Änderungen gestossen (3.51.6.20200515), das man mit
/etc/config/NoFSTRIM
/etc/config/NoBadBlocksCheck
selber entscheiden kann ob man es nutzen will.
Danke dafür.

Bin jetzt dabei RaspberryMatic neu aufzusetzen und werde dazu eine USB Stick nützen.

Gruss,

ejdv

[LibertyX]

Aber anscheinend ist gerade fstrim etwas was unerwünschte Fehler verursachen kann bei SD Karten.

TRIM ist ein ATA Befehl der dem Speichercontroller (welcher sich auf dem Speichermedium befindet) nicht mehr genutzte Blöcke meldet, damit er diese nicht weiter vorhält und beim nächsten Schreibvorgang überschreibt. Durch einen TRIM Befehl findet kein direkter Schreib-/Löschvorgang statt.

Die SD Karten Spezifikation sieht den TRIM Befehl überhaupt nicht vor, sondern lediglich den ERASE Befehl, daher wird TRIM von SD Karten nicht unterstützt, zumindest sind mir keine bekannt die das tun.

Ich sehe also nicht, wo TRIM ein Problem / Fehler bei SD Karten hervorrufen könnte, da wie gesagt, mir keine SD Karte bekannt ist, die den TRIM Befehl unterstützt.

[jmaus]

Aber anscheinend ist gerade fstrim etwas was unerwünschte Fehler verursachen kann bei SD Karten.

TRIM ist ein ATA Befehl der dem Speichercontroller (welcher sich auf dem Speichermedium befindet) nicht mehr genutzte Blöcke meldet, damit er diese nicht weiter vorhält und beim nächsten Schreibvorgang überschreibt. Durch einen TRIM Befehl findet kein direkter Schreib-/Löschvorgang statt.

Die SD Karten Spezifikation sieht den TRIM Befehl überhaupt nicht vor, sondern lediglich den ERASE Befehl, daher wird TRIM von SD Karten nicht unterstützt, zumindest sind mir keine bekannt die das tun.

Ich sehe also nicht, wo TRIM ein Problem / Fehler bei SD Karten hervorrufen könnte, da wie gesagt, mir keine SD Karte bekannt ist, die den TRIM Befehl unterstützt.

Dies entspricht in der Tat auch dem was ich bei meinen Recherchen und Tests so herausgefunden habe. Das einzige was ich hier/da jedoch noch gelesen habe ist das vmtl. irgendwann in den ATA Treiber des RaspberryPi ein Mapping des TRIM zu CMD_ERASE hinzugefügt wurde. Deshalb gibt fstrim bei der Nutzung mit einem RaspberryPi bzw. einer SD Karte in einem RaspberryPi auch keine offensichtlichen Fehler aus und es sieht in der Tat sogar so aus als ob der Befehl erfolgreich durchläuft.

Im anderen Thread habe ich dazu bereits etwas geschrieben (siehe viewtopic.php?f=65&t=58684&p=582071#p582071). Da ich aber zur Zeit keinen RaspberryPi zur Hand habe kann ich dort momentan selbst die Hinweise bzw. Tests von Stackexchange (https://unix.stackexchange.com/question ... 5880#85880) nicht durchführen um selbst zu überprüfen ob ggf. das fstrim doch irgendwelche Dinge auf der SD Karte ausführt die die Probleme erklären könnten. Vielleicht kann einer der Anwesenden das ja mal anhand der Anleitung von Stackexchange nachprüfen und hier berichten. Momentan geh ich aber immer noch davon aus das es kein problem sein sollte das fstrim kommando auf einem RaspberryPi (und zusätzlich auf allen anderen Platformen) regelmäßig (1x die Woche) auszuführen.