ubuntuusers.de

Was Du suchst, also der Timestamp, ist doch schon im Wiki-Beispiel enthalten.

1

echo "*** $(date -R) ***" >> $LOG

Wozu das Rad von vorne erfinden?

linrunner schrieb:

Was Du suchst, also der Timestamp, ist doch schon im Wiki-Beispiel enthalten.

1	echo "*** $(date -R) ***" >> $LOG

Wozu das Rad von vorne erfinden?

Weil das hier bei mir in der CLI nicht geht (weil nur sudo, nicht Benutzer root?):

@weekly					root	echo "*** $(date -R) ***" && fstrim -v / >>  /var/log/fstrim.log

Ausgabe:

*** Sat, 09 Mar 2013 07:36:28 +0100 ***
bash: /var/log/fstrim.log: Keine Berechtigung

Oder muss ich das Datum extra reinschieben, also so:

@weekly					root	echo "*** $(date -R) >>/var/log/fstrim.log ***" && fstrim -v / >>  /var/log/fstrim.log

Fragende Grüße LAZA

So funktioniert es bei mir:

1
2
3
4
5

#!/bin/sh
LOG=/var/log/batched_discard.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
fstrim -v /home >> $LOG

Gruß

ph274

Nimm das Skript aus dem Wiki so wie es da steht, das kannst Du auch von Hand ausführen.

in meinen Augen macht der Artikel aus Online-Discard eine Hexenjagd. Als nicht fachkundiger User würde ich mir so Online-Discard nie einstellen obwohl es eher der Standard ist. Ich hab es hier seit 11.10 im Einsatz und kann weder Geschwindigkeitsprobleme noch Ausfälle berichten.

Vlt sollte man dort lieber direkt die Modelle benennen, die dort Probleme haben? IMHO sind das nur wenige SSDs der ersten Generation ohne Firmwareupdate.

Sehe ich auch so. Erst das "kann [...] reduzieren", aber dann wird generell zum Deaktivieren geraten?! Habe unterschiedlichste SSDs mit online discard genutzt im Laufe der Jahre und nie solche Probleme gehabt

Huhu!

Wie damals™ hier im Thread geschrieben, stammten die aktualisierten Infos aus der c't Linux. Das stand dort so drin. Ergo habe ich es so übernommen.

Bei A funzt X, bei B nicht, dafür aber Y, was wiederum bei A nicht funzt usw 😉 Will heißen: Es gibt immer mehrere Wege nach Rom.

Liebe Grüße,

Flo

Wenn wir schon dabei sind:

• Das Kapitel über wiper.sh kann raus, ist völlig obsolet

• Das Kapitel "TRIM mit Festplattenverschluesselung" gilt für Batched und Online Discard gleichermaßen, ich würde es daher nach hinten schieben. Außerdem ist dort der Eintrag in /etc/crypttab völlig hinreichend, die Bootoptionen können ganz weg (ist mMn aus dem Arch Wiki abgepinnt und war für Ubuntu nie nötig)

Huhu linrunner,

beide Punkte erledigt. Danke für die Hinweise.

Liebe Grüße,

Flo

PS: Ich habe darum gebeten, Dein Posting in diesen Thread (TRIM) verschieben zu lassen.

Danke für's Verschieben 😉. Ich hab den Absatz mit update-initramfs wieder aufgenommen, da war ich auch zu wortkarg bei meiner Anmerkung.

Huhu!

Oh, ja. Danke, linrunner. Da ist dem Zensor mir wohl zu viel unter den Cursor geraten.

Liebe Grüße,

Flo

Ich schlage vor, die eben von ryiden im Abschnitt "Batched Discard" aufgenommene Warnung vor der Verwendung von TRIM bei Liteon SSDs wieder zu entfernen.

Begründung:

• In der verlinkten Liteon FAQ steht lediglich dass Liteon SSDs TRIM nicht benötigt ("user do not need to execute a TRIM command"). Eine Warnung vor der Verwendung von TRIM wird an keiner Stelle der FAQ ausgesprochen

• Weiter schreibt ryiden: "Bei solchen SSDs ist zu beobachten, dass der fstrim-Befehl bei jedem Durchlauf den gesamten unbenutzen Festplattenspeicher trimmt. Solches Verhalten kann sich durchaus negativ auf die Lebensdauer der SSD auswirken.". Dass beim Batched Discard stets der gesamte freie Bereich getrimmt wird ist Absicht und liegt in der Natur des Sache. Negative Auswirkungen dadurch sind pure Spekulation ohne Belege.

Fazit: ich halte die Warnung ohne konkrete Belege für nicht gerechtfertigt.

EDITH: hat sich erledigt.

Huhu.

Ich würde gerne noch einbauen, wie man Kernel-TRIM bei LUKS mit LVM testen kann, das wird allerdings etwas länger, soll es in einen Unterartikel oder direkt unter den normalen Trimtest drunter?

http://blog.alexanderkoch.net/2011/testing-trim-with-luks-on-lvm/

Oder eine allgemeine Methode die für alles (außer virtuelle Dateisysteme wie ecryptfs) funktioniert?

Der Blog-Post behandelt z.B. keine verteilten/fragmentierten LVs, und der dmsetup ist schwer zu lesen, und hdparm ist da unnötig umständlich mit seinem read-sector das nur auf echten Blockdevices funktioniert.

Alternative Methode mit yes, dd, filefrag:

# yes | dd iflag=fullblock bs=1M count=1 of=trim.test
1+0 records in
1+0 records out
1048576 bytes (1.0 MB) copied, 0.0219771 s, 47.7 MB/s
# filefrag -s -e trim.test
Filesystem type is: 58465342
File size of trim.test is 1048576 (256 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     255:     231609..    231864:    256:             eof
trim.test: 1 extent found
# df trim.test
Filesystem           1K-blocks    Used Available Use% Mounted on
/dev/mapper/lvm-root  14548992 8867704   5681288  61% /

Da haben wir (in Reihenfolge der Hervorhebung) die Blockgröße (4096), das Offset (231609), die Länge (256) und das Gerät (/dev/mapper/lvm-root). Das ist in dem Fall XFS auf LVM auf LUKS auf MD-RAID, aber das ist ja wurscht.

Daraus kann man jetzt mal einen Block lesen mit dd.

# dd bs=4096 skip=231609 count=256 if=/dev/mapper/lvm-root | 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.|
*
256+0 records in
256+0 records out
1048576 bytes (1.0 MB) copied, 0.060255 s, 17.4 MB/s
00100000

Da sieht man dann schön das yes-pattern y.y.y.y. das sich durchgehend wiederholt *.

Wenn TRIM aktiv ist, sollte sich diese Ausgabe drastisch ändern.

Ohne TRIM:

# rm trim.test
# sync
# dd bs=4096 skip=231609 count=256 if=/dev/mapper/lvm-root | 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.|
*
256+0 records in
256+0 records out
1048576 bytes (1.0 MB) copied, 0.060255 s, 17.4 MB/s
00100000

Mit TRIM (unverschlüsseltes Gerät):

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

Mit TRIM (verschlüsseltes Gerät):

00000000  1f c9 55 7d 07 15 00 d1  4a 1c 41 1a 43 84 15 c0  |..U}....J.A.C...|
00000010  24 35 37 fe 05 f7 43 93  1e f4 3c cc d8 83 44 ad  |$57...C...<...D.|
00000020  46 80 c2 26 13 06 dc 20  7e 22 e4 94 21 7c 8b 2c  |F..&... ~"..!|.,|
00000030  1f 48 0e 4e 30 f3 63 e1  15 b8 aa 1e d3 ec ef 48  |.H.N0.c........H|
00000040  91 04 cd eb 49 10 3a 40  df b8 72 c2 a5 e3 4a 6e  |....I.:@..r...Jn|
00000050  62 aa b0 97 a1 4d 1a c8  0a 4a ef fa f2 da 5a a9  |b....M...J....Z.|
00000060  2e 89 db be 31 40 f3 85  44 9d fe a3 8d a7 f4 e8  |....1@..D.......|
...

Das ist tatsächlich die elegantere Methode.

Warum funktioniert das Trim bei der Verschlüsselung nicht? Handelt es sich da um Hardwareverschlüsselung oder um LUKS?