Cronjob /sbin/fstrim macht ärger.

[deimos]

Hi,

klar erzeugt fstrim immer auch Schreiboperationen: Auch wenn die Blöcke ggf. mangels TRIM Unterstützung nicht gelöscht werden, so wird in den Metadaten des Filesystems auf jeden Fall markiert, dass die Blöcke von fstrim bearbeitet wurden. Und grade das ist bei SD Karten kritisch, weil die kein Wearleveling erfolgt und die Metadaten so dauerhaft in den gleichen physikalischen Zellen verbleiben, welche dann ggf. deutlich erhöhte Schreibzyklen im Vergleich zu den anderen Zellen aufweisen.
Ich persönlich kann von einem täglichen oder noch häufigerem fstrim nur abraten.

Viele Grüße
Alex

[g55]

hi,
auch ich hab mich die letzten Tage intensiv mit fstrim beschäftigt, hier meine 2ct :

• fstrim macht auf SD-Karten nun mWn. wirklich keinen Sinn. Kein Wear-leveling, kein Trim-Support
  und wenn Alex schreibt, dass mit fstrim bei SD-Karten Schreib-Zugriffe erfolgen, glaub ich das, mach mich jedoch stutzig, weil unnötig.
• fstrim ist doch eigentlich nur für unterstützte Geräte, also SSDs nötig ... und dann auch nur im Linux, wenn für Wear-Leveling nicht genug Platz frei gelassen wurde, oder ?
• fstrim ist weiterhin nach meine Recherchen durchaus empfohlen, wenn man so was wie ich einsetzt : LVM mit Thin-Provisioning. Machen virtuelle Umgebungen wie Proxmox etc. wohl auch nicht anders. Hier werden z.B. der Platz für gelöschte snapshots erst an das "untergeordnete Dateisystem" freigegeben mit fstrim. Hab ich getestet. is so
• im systemd gibt es den service "fstrim.service", der ruft auf : "fstrim -Av".
  ist irgendwie blöd auf Raspies o.a., denn das "A" bedeutet, nimm fstab ... schon ist die SD-Karte bei mir zumindest mit der boot-Partition auch dabei

Korrigiert mich, wenn ich was falsch sehe, aber ich schlage aus den bisherigen Posts und meinen bisherigen Erkenntnissen folgendes vor:

• never ever use fstrim on SD cards
• if SSD and enough unprovisioned space (=wear level) then fstrim is not needed
• use fstrim per default only max. weekly
• wenn viele Daten geschrieben/gelöscht werden, z.B. snapshots erzeugen / löschen, kann man fstrim auch manuell starten, um den Platz freizugeben. das ist wohl nicht das übliche Scenario in einer Live-Installation
• für "special configs" wie LVM-Thin, Proxmox und andere virtuelle Umgebungen ist fstrim mMn. unverzichtbar.
• @Jens : ich würde daher vorschlagen, auch im Raspberrymatic erst mal gar kein fstrim per default einzubauen, schon gar nicht täglich

wie gesagt, meine 2ct. Ich könnte ja auch was übersehen haben

PS : ich freue mich immer, wenn ich aus den Rückmeldungen von euch Experten was dazu lernen kann

[ejdv]

Im anderen Thread habe ich dazu bereits etwas geschrieben (siehe viewtopic.php?f=65&t=58684&p=582071#p582071).

Bin jetzt auf USB Stick umgestiegen und konnte also den Test mit der SD Karte ausprobieren.
Habe die SD Karte neu formatiert und geflashed (3.51.6.20200517).

Code: Alles auswählen

root@raspberry-matic:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               975.9M    511.0M    397.7M  56% /
devtmpfs                479.9M         0    479.9M   0% /dev
tmpfs                   484.4M         0    484.4M   0% /dev/shm
tmpfs                   484.4M    116.0K    484.3M   0% /tmp
tmpfs                   484.4M     96.0K    484.3M   0% /run
tmpfs                   484.4M    420.0K    484.0M   0% /var
tmpfs                   484.4M     68.0K    484.3M   0% /media
/dev/mmcblk0p3           13.2G    101.3M     12.4G   1% /usr/local
/dev/mmcblk0p1          255.7M     47.5M    208.3M  19% /boot

root@raspberry-matic:~# cd /usr/local

root@raspberry-matic:/usr/local# yes | dd iflag=fullblock bs=1M count=1 of=trim.test
1+0 records in
1+0 records out
1048576 bytes (1.0MB) copied, 0.086501 seconds, 11.6MB/s

root@raspberry-matic:/usr/local# ls -als trim.test
  1024 -rw-r--r--    1 root     root       1048576 May 21 15:08 trim.test

root@raspberry-matic:/usr/local# filefrag -s -v trim.test
Filesystem type is: ef53
File size of trim.test is 1048576 (256 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..      15:    1099808..   1099823:     16:
   1:       16..     255:      38992..     39231:    240:    1099824: last,eof
trim.test: 2 extents found

root@raspberry-matic:/usr/local# df trim.test
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p3        13847588    104716  13019724   1% /usr/local


root@raspberry-matic:/usr/local# dd bs=4096 skip=1099808 count=16 if=/dev/mmcblk0p3 | hexdump -C
16+0 records in
16+0 records out
65536 bytes (64.0KB) copied, 0.015744 seconds, 4.0MB/s
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
00010000
root@raspberry-matic:/usr/local# dd bs=4096 skip=38992 count=240 if=/dev/mmcblk0p3 | hexdump -C
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
240+0 records in
240+0 records out
983040 bytes (960.0KB) copied, 0.094923 seconds, 9.9MB/s
000f0000

root@raspberry-matic:/usr/local# rm -f trim.test

root@raspberry-matic:/usr/local# sync

root@raspberry-matic:/usr/local# fstrim -v /usr/local
fstrim: /usr/local: FITRIM ioctl failed: Input/output error

@raspberry-matic:/usr/local# echo 1 > /proc/sys/vm/drop_caches

@raspberry-matic:/usr/local# dd bs=4096 skip=1099808 count=16 if=/dev/mmcblk0p3 | hexdump -C
-sh: hexdump: Input/output error
-sh: dd: Input/output error

@raspberry-matic:/usr/local# dd bs=4096 skip=38992 count=240 if=/dev/mmcblk0p3 | hexdump -C
-sh: hexdump: Input/output error
-sh: dd: Input/output error

Das fstrim Kommand macht das System nutzlos (Input/output error), wie schon erwähnt.
System neu gebootet.

Code: Alles auswählen

root@raspberry-matic:~# cd /usr/local/
root@raspberry-matic:/usr/local# dd bs=4096 skip=1099808 count=16 if=/dev/mmcblk0p3 | hexdump -C
16+0 records in
16+0 records out
65536 bytes (64.0KB) copied, 0.014865 seconds, 4.2MB/s
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
00010000
root@raspberry-matic:/usr/local# dd bs=4096 skip=38992 count=240 if=/dev/mmcblk0p3 | hexdump -C
00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|
*
240+0 records in
240+0 records out
983040 bytes (960.0KB) copied, 0.095267 seconds, 9.8MB/s
000f0000

Man sieht das fstrim an sich nichts macht (Pattern bleibt y.y.y.y.y.y.y.y.) , ausser das man nicht mehr auf das System zugreifen kann.
Lösung für SD Karten Nutzer (IMHO) ist also crontab:

Code: Alles auswählen

0 3 * * 0 [ ! -e /etc/config/NoFSTRIM ] && /bin/nice /sbin/fstrim --all --quiet >/dev/null 2>/dev/null

Und:

Code: Alles auswählen

touch /etc/config/NoFSTRIM

MfG,

ejdv

[jmaus]

Im anderen Thread habe ich dazu bereits etwas geschrieben (siehe viewtopic.php?f=65&t=58684&p=582071#p582071).

Bin jetzt auf USB Stick umgestiegen und konnte also den Test mit der SD Karte ausprobieren.
Habe die SD Karte neu formatiert und geflashed (3.51.6.20200517).

Bitte mach diese Tests noch einmal mit einer komplett fabrikneuen SD Karte und nicht mit der alten die ja bekanntermaßen wohl ein Problem hat bzw. defekt ist denn so lässt sich nicht IMHO zweifelsfrei feststellen das das fstrim kommando wirklich hier der ausschlaggebende Punkt ist/war.

[ejdv]

Bitte mach diese Tests noch einmal mit einer komplett fabrikneuen SD Karte

Sorry, ich habe keine "komplett fabrikneuen SD Karte" und werde auch keine Kaufen.
Kann nur sagen, das ich mit dem USB Stick keine Problem habe, wobei aber auffällt dass das Verhalten mit Mountpoint oder --all, sich von Output her unterscheidet.
Wahrscheinlich wird bei Verwendung des Mountpoints das "discard operation support" geprüft und bei --all nicht, aber das geht zu tief.

Für mich war die Lösung eine neu Installation, in diesem Fall auf einem USB Stick, wobei ich hoffe das der länger aushält wie eine neue SD Karte.
Danke nochmals für die Empfehlung.
Und dabei wollte ich es gerne belassen.

Code: Alles auswählen

root@raspimatic:~# yes | dd iflag=fullblock bs=1M count=1 of=/usr/local/trim.test
1+0 records in
1+0 records out
1048576 bytes (1.0MB) copied, 0.086869 seconds, 11.5MB/s
root@raspimatic:~# rm -f /usr/local/trim.test
root@raspimatic:~# sync
root@raspimatic:~# /sbin/fstrim --verbose /usr/local
fstrim: /usr/local: the discard operation is not supported

Code: Alles auswählen

root@raspimatic:~# yes | dd iflag=fullblock bs=1M count=1 of=/usr/local/trim.test
1+0 records in
1+0 records out
1048576 bytes (1.0MB) copied, 0.084609 seconds, 11.8MB/s
root@raspimatic:~# rm -f /usr/local/trim.test
root@raspimatic:~# sync
root@raspimatic:~# /sbin/fstrim --all --verbose
root@raspimatic:~#

MfG,

ejdv

[rr745]

kann doch nicht sein das der raspi dadurch abstürzt und man dies nicht disablen kann. ich mache von mir aus regelmässig/unregelmässig ein image meiner sd karte, soeiw backups auf stick.

meine sd karte habe ich nun mehrmals mittels knoppix überprüft, es wurden keine fehler gefunden.
hab nun /sbin/fstrim --all --quiet >/dev/null 2>/dev/null
ausgeremt. ich finde man sollte es dem user üerlassen ob es durchgeführt wird, oder nicht.

[jp112sdl]

ich finde man sollte es dem user üerlassen ob es durchgeführt wird, oder nicht.

Klar doch... Ist kein Problem:
Einstellungen > Systemsteuerung >Erweiterte Einstellungen
Haken raus bei FSTRIM

[rr745]

ich finde man sollte es dem user üerlassen ob es durchgeführt wird, oder nicht.

Klar doch... Ist kein Problem:
Einstellungen > Systemsteuerung >Erweiterte Einstellungen
Haken raus bei FSTRIM

du bist der beste !!!! hatte ich noch gar nicht gesehen.....vielen, vielen dank !!!!!!!

[wzo481]

Ich hatte nun bei einer fabrikneuen SD Karte das Problem, dass die Charly CCU3 jeden Samstagmorgen tot war. Es half nur noch Power off / Power on. Gemäss Alarmierungssystem passierte es immer etwa kurz nach 04:00. Im Crontab habe ich dort dann diesen Eintrag gefunden:

0 4 * * 6 [ ! -e /etc/config/NoFSTRIM ] && /bin/nice /sbin/fstrim --all --quiet >/dev/null 2>/dev/null

Das hat mich dann letztlich in diesen Thread geführt. Ich habe den Haken bei FSTRIM mal rausgenommen und hoffe, dass es nächsten Samstag dann nicht mehr passiert.