Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TRIM bei USB SSD?

32 views
Skip to first unread message

Ulli Horlacher

unread,
Mar 30, 2022, 4:01:38 AM3/30/22
to
TRIM ist bei SSD sinnvoll und wird normalerweise von systemd einmal pro
Woche ausgefuehrt:

root@moep:~# systemctl | grep trim
fstrim.timer loaded active waiting Discard unused blocks once a week


Was macht man aber mit USB SSDs, die nur sporadisch eingesteckt werden?

Beispiel:

root@moep:~# smartctl -a /dev/sdb | egrep 'Device|TRIM'
Device Model: Samsung Portable SSD T5
LU WWN Device Id: 5 002538 e00000000
Rotation Rate: Solid State Device
TRIM Command: Available, deterministic, zeroed

root@moep:~# man fstrim
(...)
Running fstrim frequently, or even using mount -o discard, might
negatively affect the lifetime of poor-quality SSD devices. For most
desktop and server systems a sufficient trimming frequency is once a
week.

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

Ulli Horlacher

unread,
Mar 30, 2022, 5:09:29 AM3/30/22
to
Thomas Noll <-_tn...@web.de> wrote:
> Am Wed, 30 Mar 2022 08:01:36 +0000 (UTC) schrieb Ulli Horlacher:
>
> > TRIM ist bei SSD sinnvoll und wird normalerweise von systemd einmal pro
> > Woche ausgefuehrt:
> >
> > root@moep:~# systemctl | grep trim
> > fstrim.timer loaded active waiting Discard unused blocks once a week
> >
> >
> > Was macht man aber mit USB SSDs, die nur sporadisch eingesteckt werden?
>
> Sporadisch trimmen.

Und wie am besten automatisieren?
Ich bin doch kein Winzigweich-Juenger und mach so was manuell.

Zeitlich bezogen ist unsinnig, wenn die SSD nur alle X Wochen
angeschlossen wird.

Ulli Horlacher

unread,
Mar 30, 2022, 5:52:00 AM3/30/22
to
Thomas Noll <-_tn...@web.de> wrote:

> >> > Was macht man aber mit USB SSDs, die nur sporadisch eingesteckt werden?
> >>
> >> Sporadisch trimmen.
> >
> > Und wie am besten automatisieren?
> > Ich bin doch kein Winzigweich-Juenger und mach so was manuell.
>
> Frequenz des Jobs erhöhen, Test auf Notwendigkeit des Trims einbauen.

Ich bin doch nicht der erste, der so was braucht?
Gibts da nix fertiges?


> (z.B. über Nutzungsdaten aus smartctl)

SMART bietet keine Nutzungshistorie.


> Ist deine sporadisch angeschlossene Platte überhaupt in der Liste, die
> von dem Job erfasst wird?

Welcher Job?


> > Zeitlich bezogen ist unsinnig, wenn die SSD nur alle X Wochen
> > angeschlossen wird.
>
> Kommt auf den Überlapp von sporadisch Anstecken und regelmässig Job ausführen an.

Achwas, wirklich?

Holger Schauer

unread,
Mar 30, 2022, 11:08:04 AM3/30/22
to
On 10437 September 1993, Ulli Horlacher wrote:
> Und wie am besten automatisieren?

udev-Rules.

> Ich bin doch kein Winzigweich-Juenger und mach so was manuell.
> Zeitlich bezogen ist unsinnig, wenn die SSD nur alle X Wochen
> angeschlossen wird.

Ich nutze das für automatisches Backup, sobald ich eine USB-Disk
anschließe. Das will ich auch nicht manuell triggern.

Holger

--
--- http://blog.find-method.de/ ---
"Keine Shell, kein Prompt, keine Kekse."
-- Jochen Hein in de.comp.os.linux.misc

Ulli Horlacher

unread,
Mar 30, 2022, 11:15:47 AM3/30/22
to
Holger Schauer <Holger....@gmx.de> wrote:
> On 10437 September 1993, Ulli Horlacher wrote:
> > Und wie am besten automatisieren?
>
> udev-Rules.

Woher soll udev wissen, wann ein TRIM notwendig ist?

Thomas Dorner

unread,
Mar 30, 2022, 12:08:02 PM3/30/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> Holger Schauer <Holger....@gmx.de> wrote:
>> On 10437 September 1993, Ulli Horlacher wrote:
>> > Und wie am besten automatisieren?
>>
>> udev-Rules.
>
> Woher soll udev wissen, wann ein TRIM notwendig ist?

Irgendwo mußt Du zählen, wie oft die Platte angestöpselt wurde. Wenn es
immer am gleichen Rechner ist, kann der das übernehmen, ansonsten
irgendwo auf der Platte selbst (z.B. Brute Force ein ansonsten
unbenutzten Sektor per dd).

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

Gerald E¡scher

unread,
Mar 30, 2022, 12:16:48 PM3/30/22
to
Ulli Horlacher schrieb am 30/3/2022 10:01:

> root@moep:~# man fstrim
> (...)
> Running fstrim frequently, or even using mount -o discard, might
> negatively affect the lifetime of poor-quality SSD devices.

Einfach keine "poor-quality SSD devices" verwenden :-) Könnte es
vielleicht sein, dass dieser Hinweis veraltet ist? Andere Betrübssysteme
haben kein Problem damit, ständig zu TRIMen und die SSDs werden dennoch
nicht kaputt.

> For most
> desktop and server systems a sufficient trimming frequency is once a
> week.

Es scheint mir disbezüglich unterschiedliche Meinungen zu geben.

--
Gerald

Ulli Horlacher

unread,
Mar 30, 2022, 12:27:48 PM3/30/22
to
Thomas Dorner <de.comp.os.unix.linux....@spamgourmet.com> wrote:

> Irgendwo mußt Du zählen, wie oft die Platte angestöpselt wurde. Wenn es
> immer am gleichen Rechner ist, kann der das übernehmen, ansonsten
> irgendwo auf der Platte selbst (z.B. Brute Force ein ansonsten
> unbenutzten Sektor per dd).

fstrim - discard unused blocks on a mounted filesystem
^^^^^^^^^^^^^^^^^^

Man muss das also pro Filesystem machen.
Aber was nimmt man als Indikator?
Zeit seit dem letzten TRIM?
Anzahl der mounts seit dem letzten TRIM?
Alles wenig ausssagekraeftig!

Bin ich denn wirklich der Erste mit dem Problem??
Muss man sich da was selber zusammenschustern?
Gibts da keine fertige Loesung?

Ulli Horlacher

unread,
Mar 30, 2022, 2:34:38 PM3/30/22
to
Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:
> Ulli Horlacher schrieb am 30/3/2022 10:01:
>
> > root@moep:~# man fstrim
> > (...)
> > Running fstrim frequently, or even using mount -o discard, might
> > negatively affect the lifetime of poor-quality SSD devices.
>
> Einfach keine "poor-quality SSD devices" verwenden :-) Könnte es
> vielleicht sein, dass dieser Hinweis veraltet ist? Andere Betrübssysteme
> haben kein Problem damit, ständig zu TRIMen und die SSDs werden dennoch
> nicht kaputt.

Gegenbeispiel:

https://www.intel.com/content/dam/support/us/en/documents/ssdc/data-center-ssds/Intel_Linux_NVMe_Guide_330602-002.pdf

Filesystem Recommendations

IMPORTANT: Do not discard blocks in filesystem usage.

Be sure to turn off the discard option when making your Linux filesystem.

Ulli Horlacher

unread,
Mar 30, 2022, 3:21:38 PM3/30/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> fstrim - discard unused blocks on a mounted filesystem
>
> Man muss das also pro Filesystem machen.
> Aber was nimmt man als Indikator?
> Zeit seit dem letzten TRIM?
> Anzahl der mounts seit dem letzten TRIM?

Ich habs jetzt in usbmount(*) eingebaut:

root@moep:/# usbmount
(...)
(usbmount ST5_1)root@moep:/usb/ST5_1# exit
TRIM btrfs filesystem on /dev/sde1 (discards deleted blocks)? yes
/usb/ST5_1: 28.3 GiB (30406037504 bytes) trimmed
umount: /usb/ST5_1 unmounted
root@moep:/#


(*) https://fex.belwue.de/linuxtools/usbmount.html

Gerald E¡scher

unread,
Mar 30, 2022, 3:38:05 PM3/30/22
to
Ulli Horlacher schrieb am 30/3/2022 20:34:

> Gerald E¡scher <Spa...@fahr-zur-hoelle.org> wrote:
>> Ulli Horlacher schrieb am 30/3/2022 10:01:
>>
>> > root@moep:~# man fstrim
>> > (...)
>> > Running fstrim frequently, or even using mount -o discard, might
>> > negatively affect the lifetime of poor-quality SSD devices.
>>
>> Einfach keine "poor-quality SSD devices" verwenden :-) Könnte es
>> vielleicht sein, dass dieser Hinweis veraltet ist? Andere Betrübssysteme
>> haben kein Problem damit, ständig zu TRIMen und die SSDs werden dennoch
>> nicht kaputt.
>
> Gegenbeispiel:
>
> https://www.intel.com/content/dam/support/us/en/documents/ssdc/data-center-ssds/Intel_Linux_NVMe_Guide_330602-002.pdf

Deine Samsung T5 hat keine NVMe Schnittstelle.

> Filesystem Recommendations
>
> IMPORTANT: Do not discard blocks in filesystem usage.
>
> Be sure to turn off the discard option when making your Linux filesystem.

Du hast nicht weiter gelesen:
"You want to allow the SSD manage
blocks and its activity between the NVM (non-volatile memory) and host with more advanced and consistent
approaches in the SSD Controller."

NVMe SSDs sollen laut Intel demnach überhaupt nicht geTRIMt werden, denn
die Verwaltung der Speicherblöcke kann die SSD selber viel besser.

--
Gerald

Marcel Mueller

unread,
Mar 30, 2022, 4:19:58 PM3/30/22
to
Am 30.03.22 um 10:01 schrieb Ulli Horlacher:
> TRIM ist bei SSD sinnvoll und wird normalerweise von systemd einmal pro
> Woche ausgefuehrt:
>
> root@moep:~# systemctl | grep trim
> fstrim.timer loaded active waiting Discard unused blocks once a week
>
>
> Was macht man aber mit USB SSDs, die nur sporadisch eingesteckt werden?

online discard

Die allerersten SSDs haben sich damit etwas schwer getan, aber die
letzten 10 Jahre hatte ich damit keine Probleme. Ich trimme *alle* SSDs
per online discard. In Laptops genauso wie in Servern oder PCs.


Marcel

Marc Haber

unread,
Mar 30, 2022, 4:46:58 PM3/30/22
to
Marcel Mueller <news.5...@spamgourmet.org> wrote:
>Die allerersten SSDs haben sich damit etwas schwer getan, aber die
>letzten 10 Jahre hatte ich damit keine Probleme. Ich trimme *alle* SSDs
>per online discard. In Laptops genauso wie in Servern oder PCs.

Da ist -o discard? Und, funktioniert das auch wenn da noch eine Lage
LUKS und eine Lage LVM dazwischen ist?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Thomas Niering

unread,
Mar 31, 2022, 12:15:40 AM3/31/22
to

Hallo Ulli,

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Was macht man aber mit USB SSDs, die nur sporadisch eingesteckt werden?

Kommt auf das Nutzungsszenario drauf an.

Im Regelfall würd ich es ignorieren und mir keine Gedanken darüber machen.

Erst, wenn die SSD als Ablageort für Datenbanken, o.ä., benutzt wird,
würd ich mir eine Lösung überlegen.

Ciao Thomas

Thomas Niering

unread,
Mar 31, 2022, 12:15:40 AM3/31/22
to

Hallo Gerald,

Gerald E¡scher <Spa...@fahr-zur-Hoelle.org> wrote:
> NVMe SSDs sollen laut Intel demnach überhaupt nicht geTRIMt werden, denn
> die Verwaltung der Speicherblöcke kann die SSD selber viel besser.

Das setzt voraus, dass die SSD überhaupt Kenntnis von vom Dateisystem
geleerten Blöcken bekommt. TRTM teilt der SSD dies mit...

Ciao Thomas

Sven Hartge

unread,
Mar 31, 2022, 4:00:03 AM3/31/22
to
Marc Haber <mh+usene...@zugschl.us> wrote:
> Marcel Mueller <news.5...@spamgourmet.org> wrote:

>> Die allerersten SSDs haben sich damit etwas schwer getan, aber die
>> letzten 10 Jahre hatte ich damit keine Probleme. Ich trimme *alle*
>> SSDs per online discard. In Laptops genauso wie in Servern oder PCs.

> Da ist -o discard? Und, funktioniert das auch wenn da noch eine Lage
> LUKS und eine Lage LVM dazwischen ist?

Ja, sofern dein Kernel nicht steinalt ist.



--
Sigmentation fault. Core dumped.

Marc Haber

unread,
Mar 31, 2022, 5:05:55 AM3/31/22
to
Sven Hartge <sh-...@svenhartge.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Marcel Mueller <news.5...@spamgourmet.org> wrote:
>
>>> Die allerersten SSDs haben sich damit etwas schwer getan, aber die
>>> letzten 10 Jahre hatte ich damit keine Probleme. Ich trimme *alle*
>>> SSDs per online discard. In Laptops genauso wie in Servern oder PCs.
>
>> Da ist -o discard? Und, funktioniert das auch wenn da noch eine Lage
>> LUKS und eine Lage LVM dazwischen ist?
>
>Ja,

Transparent? Ich muss nur ein Backup machen und -o discard setzen?

> sofern dein Kernel nicht steinalt ist.

Von letzter Woche ;-)

Sven Hartge

unread,
Mar 31, 2022, 5:35:55 AM3/31/22
to
Marc Haber <mh+usene...@zugschl.us> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:
>> Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Marcel Mueller <news.5...@spamgourmet.org> wrote:

>>>> Die allerersten SSDs haben sich damit etwas schwer getan, aber die
>>>> letzten 10 Jahre hatte ich damit keine Probleme. Ich trimme *alle*
>>>> SSDs per online discard. In Laptops genauso wie in Servern oder
>>>> PCs.
>>
>>> Da ist -o discard? Und, funktioniert das auch wenn da noch eine Lage
>>> LUKS und eine Lage LVM dazwischen ist?
>>
>> Ja,

> Transparent? Ich muss nur ein Backup machen und -o discard setzen?

Dem sollte so sein, ja.

LUKS braucht noch "discard" in der crypttab ("Allow using of discards
(TRIM) requests for device.") und in LVM sollte man "issue_discards = 1"
konfigurieren, damit beim Löschen von LVs (d.h. auch beim Löschen von
Snapshots) die Bereich auch gleich geTRIMMt werden, die dadurch frei
werden.

LVM (bzw. der Device-Mapper) reicht Discards schon per Default durch,
seit einiger Zeit.

Gerald E¡scher

unread,
Mar 31, 2022, 6:12:40 AM3/31/22
to
Thomas Niering schrieb am 31/3/2022 06:13:

> Gerald E¡scher <Spa...@fahr-zur-Hoelle.org> wrote:
>> NVMe SSDs sollen laut Intel demnach überhaupt nicht geTRIMt werden, denn
>> die Verwaltung der Speicherblöcke kann die SSD selber viel besser.
>
> Das setzt voraus, dass die SSD überhaupt Kenntnis von vom Dateisystem
> geleerten Blöcken bekommt.

Diese Kenntnis erhält sie, wenn ein Speicherblock überschrieben werden
soll. Dann weiß sie, dass der ursprüngliche Inhalt nicht mehr benötigt
wird, kann diesen verwerfen und die neuen Daten werden in einem anderen,
leeren Speicherblock abgelegt.

> TRTM teilt der SSD dies mit...

Wenn Intel der Meinung ist, dass TRIM bei NVMe SSDs kontraproduktiv ist
und der Controller der SSD die Speicherblöcke besser verwalten kann
als das Dateisystem, dann würde ich mich danach richten.

--
Gerald

Sieghard Schicktanz

unread,
Mar 31, 2022, 2:13:04 PM3/31/22
to
Hallo Ulli Horlacher,

Du schriebst am Wed, 30 Mar 2022 16:27:47 +0000 (UTC):

> fstrim - discard unused blocks on a mounted filesystem
> ^^^^^^^^^^^^^^^^^^
...
> Bin ich denn wirklich der Erste mit dem Problem??

Möglich. SSDs sind keine Archiv-Datenträger, die brrauchen laufend
"Bewegung", aber zumindest Stromversorgung, um ihren Datenerhalt zu
sichern.

> Muss man sich da was selber zusammenschustern?
> Gibts da keine fertige Loesung?

Wohl.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

Sieghard Schicktanz

unread,
Mar 31, 2022, 2:13:05 PM3/31/22
to
Hallo Gerald E¡scher,

Du schriebst am 30 Mar 2022 16:16:47 GMT:

> > Running fstrim frequently, or even using mount -o discard, might
> > negatively affect the lifetime of poor-quality SSD devices.
>
> Einfach keine "poor-quality SSD devices" verwenden :-) Könnte es
> vielleicht sein, dass dieser Hinweis veraltet ist? Andere

Datenträger, die darauf angewiesen sind, immer zu wissen, welche Blöcke
für Umschichtungen verfügbar sind und nicht nur dafür eine dauernd
verfügbare Stromversorgung u haben, _SIND_ (IMHO) "poor quality".

> Betrübssysteme haben kein Problem damit, ständig zu TRIMen und die
> SSDs werden dennoch nicht kaputt.

Nicht schnell genug, um aufzufallen. Außedem macht (eher) nicht das
"TRIM" die SSD kaputt, sondern die laufenden Umlagerungen, die
besonders bei hohem Füllgrad kräftig ins Kontor schlagen können.

> > For most
> > desktop and server systems a sufficient trimming frequency is
> > once a week.
>
> Es scheint mir disbezüglich unterschiedliche Meinungen zu geben.

Es ist jedenfalls nicht häufiger nötig als Dateien gelöscht werden
und dadurch Blöcke freiwerden _könnten_. "Könnten", weil die
"Vorstellungen" von Blöcken bei SSD (-Betriebssystem) und Dateisystem
durchaus inkongruent sein können.

(Doch, ich habe auch eine SSD in Betrieb. Die behauptet auch nach
mehreren Jahren noch, vollständig in Ordnung zu sein. Die ist
allerdings auch nur zu - jetzt - ca. 2/3 belegt, vorsichtigkeitshalber.)

Thomas Dorner

unread,
Mar 31, 2022, 2:37:23 PM3/31/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> fstrim - discard unused blocks on a mounted filesystem
> ^^^^^^^^^^^^^^^^^^
>
> Man muss das also pro Filesystem machen.
> Aber was nimmt man als Indikator?
> Zeit seit dem letzten TRIM?
> Anzahl der mounts seit dem letzten TRIM?
> Alles wenig ausssagekraeftig!

Ich würde die mounts nehmen. Letztlich ist der reguläre 1 Mal pro Woche
genauso geraten, da es ja eigentlich von der Anzahl der Schreibvorgänge
abhängt.

Sieghard Schicktanz

unread,
Mar 31, 2022, 4:13:05 PM3/31/22
to
Hallo Ulli Horlacher,

Du schriebst am Wed, 30 Mar 2022 18:34:37 +0000 (UTC):

> Filesystem Recommendations
>
> IMPORTANT: Do not discard blocks in filesystem usage.
>
> Be sure to turn off the discard option when making your Linux
> filesystem.

Das ist schon in Ordnung so: "when _making_ your [Linux] filesystem."
Da wird ja kreuz und quer geschrieben und wieder gelöscht, verschoben
und überschieben - das könnte zu "hot spots" in den Chips führen, und
_die_ kann der Controller von sich aus viel besser verwalten und
vermeiden.
Für den späteren _Betrieb_ dieses Systems muß das aber nicht mehr
gelten. Das sollte dann aber auch irgendwo in der Beschreibung erwähnt
sein.

Marcel Mueller

unread,
Mar 31, 2022, 4:13:50 PM3/31/22
to
Am 30.03.22 um 22:46 schrieb Marc Haber:
> Da ist -o discard? Und, funktioniert das auch wenn da noch eine Lage
> LUKS und eine Lage LVM dazwischen ist?

Im Prinzip ja.
Das gilt aber für Batch-Trim gleichermaßen.

Aber das ist immer eine Sicherheitslücke.
Durch das Trim auf dem verschlüsselten Volume sickern im Prinzip
unverschlüsselte Informationen auf den Datenträger durch. Wenn man die
aus der SSD extrahieren kann, kann man damit die Free-Space-Bitmaps des
Dateisystems rekonstruieren, hat also unverschlüsselte Informationen.
Das wiederum ist ein Ansatzpunkt, um die Verschlüsselung zu knacken.

Über die Größe dieser Lücke gibt es unterschiedliche Meinungen.
Ich selbst arbeite auch an einer solchen Konfiguration. Ob ich damals
noch irgendeinen Schalter bei LUKS umlegen musste, um Trim
durchzureichen, weiß ich ehrlich gesagt nicht mehr.


Marcel

Marcel Mueller

unread,
Mar 31, 2022, 4:27:08 PM3/31/22
to
Am 31.03.22 um 11:05 schrieb Marc Haber:
> Transparent? Ich muss nur ein Backup machen und -o discard setzen?

Ein Backup sollte man immer mal machen, aber die discard Option ist kein
Kompatibilitätsbruch. Man kann sie jederzeit setzen oder entfernen.

Man sollte halt den Batch-Trim-Job dann aussetzen. Das wäre sonst
doppelt gemoppelt.
systemctl disable fstrim.timer


Marcel

Marc Haber

unread,
Apr 4, 2022, 9:47:03 AM4/4/22
to
Sven Hartge <sh-...@svenhartge.de> wrote:
>LUKS braucht noch "discard" in der crypttab ("Allow using of discards
>(TRIM) requests for device.") und in LVM sollte man "issue_discards = 1"
>konfigurieren, damit beim Löschen von LVs (d.h. auch beim Löschen von
>Snapshots) die Bereich auch gleich geTRIMMt werden, die dadurch frei
>werden.
>
>LVM (bzw. der Device-Mapper) reicht Discards schon per Default durch,
>seit einiger Zeit.

Also, ich hab jetzt mal überall (crypttab, fstab) discard
reingeschrieben. lsblk --discard sieht jetzt so aus:

|sdb 0 512B 2G 0
|+-sdb1 0 512B 2G 0
|+-sdb2 0 512B 2G 0
|+-sdb3 0 512B 2G 0
| +-fan-c_boot 0 512B 2G 0
| ¦ +-boot 0 512B 2G 0
| +-fan-c_kernel32 0 512B 2G 0
| ¦ +-kernel32 0 512B 2G 0
| +-fan-c_kernel64 0 512B 2G 0
| ¦ +-kernel64 0 512B 2G 0
| +-fan-c_kernelhome 0 512B 2G 0
| ¦ +-kernelhome 0 512B 2G 0
| +-fan-c_spinturn 0 512B 2G 0
| ¦ +-spinturn 0 0B 0B 0
| +-fan-c_swap0 0 512B 2G 0
| ¦ +-swap0 0 512B 2G 0
| +-fan-c_root 0 512B 2G 0
| ¦ +-root 0 512B 2G 0

fan-c_spinturn ist eine crypto-LV in der ein Plattenimage für eine
KVM-VM liegt, wie bekomme ich da discard aktiviert?

Bei rotierendem Rost ist discard irrelevant, richtig?

Auf dem Notebook, das diese Operation noch nicht hinter sich hat (und
btrfs verwendet), sieht lsblk --discard so aus:

|NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
|sda 0 4K 2G 0
|+-sda1 3072 4K 2G 0
|+-sda2 0 4K 2G 0
|+-sda3 0 4K 2G 0
| +-drop-c_boot 0 4K 2G 0
| ¦ +-boot 0 0B 0B 0
| +-drop-c_swap0 0 4K 2G 0
| ¦ +-swap0 0 0B 0B 0
| +-drop-c_dropbtr0 0 4K 2G 0
| ¦ +-dropbtr0 0 0B 0B 0

Was ist mit discard für swap? Sinnvoll? Unnötig? Kontraproduktiv?

Sven Hartge

unread,
Apr 4, 2022, 10:02:35 AM4/4/22
to
Ist die LV vielleicht nicht aktiv und daher wird das nicht angezeigt?

> Bei rotierendem Rost ist discard irrelevant, richtig?

Ja. Es könnte noch bei SMR-Platten wichtig/interessant sein, aber da
fehlen mir die Infos.

> Auf dem Notebook, das diese Operation noch nicht hinter sich hat (und
> btrfs verwendet), sieht lsblk --discard so aus:

> |NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
> |sda 0 4K 2G 0
> |+-sda1 3072 4K 2G 0
> |+-sda2 0 4K 2G 0
> |+-sda3 0 4K 2G 0
> | +-drop-c_boot 0 4K 2G 0
> | ¦ +-boot 0 0B 0B 0
> | +-drop-c_swap0 0 4K 2G 0
> | ¦ +-swap0 0 0B 0B 0
> | +-drop-c_dropbtr0 0 4K 2G 0
> | ¦ +-dropbtr0 0 0B 0B 0

> Was ist mit discard für swap? Sinnvoll? Unnötig? Kontraproduktiv?

Schon nötig, würde ich sagen. Der Platz der auslagerten und wieder
eingelagerten Daten will man ja schon dem SSD-Controller mitteilen,
damit dieser nicht unnötig verwaiste Speicherseiten von vor 2 Wochen
noch hin- und herschiebt.

Gerald E¡scher

unread,
Apr 4, 2022, 10:23:38 AM4/4/22
to
Sven Hartge schrieb am 4/4/2022 16:02:

> Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> Bei rotierendem Rost ist discard irrelevant, richtig?
>
> Ja. Es könnte noch bei SMR-Platten wichtig/interessant sein, aber da
> fehlen mir die Infos.

Es existieren SMR-Platten, die geTRIMt werden können.
https://de.wikipedia.org/wiki/Shingled_Magnetic_Recording#Verbreitung
Blöd, wenn etwas irrtümlich gelöscht wurde und kein Backup vorhanden.
Nach dem TRIM helfen auch Datenrettungswerkzeuge nichts mehr.

--
Gerald

Marc Haber

unread,
Apr 5, 2022, 2:49:29 AM4/5/22
to
Sven Hartge <sh-...@svenhartge.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> |sdb 0 512B 2G 0
>> |+-sdb1 0 512B 2G 0
>> |+-sdb2 0 512B 2G 0
>> |+-sdb3 0 512B 2G 0
>> | +-fan-c_boot 0 512B 2G 0
>> | ¦ +-boot 0 512B 2G 0
>> | +-fan-c_kernel32 0 512B 2G 0
>> | ¦ +-kernel32 0 512B 2G 0
>> | +-fan-c_kernel64 0 512B 2G 0
>> | ¦ +-kernel64 0 512B 2G 0
>> | +-fan-c_kernelhome 0 512B 2G 0
>> | ¦ +-kernelhome 0 512B 2G 0
>> | +-fan-c_spinturn 0 512B 2G 0
>> | ¦ +-spinturn 0 0B 0B 0
>> | +-fan-c_swap0 0 512B 2G 0
>> | ¦ +-swap0 0 512B 2G 0
>> | +-fan-c_root 0 512B 2G 0
>> | ¦ +-root 0 512B 2G 0
>
>> fan-c_spinturn ist eine crypto-LV in der ein Plattenimage für eine
>> KVM-VM liegt, wie bekomme ich da discard aktiviert?
>
>Ist die LV vielleicht nicht aktiv und daher wird das nicht angezeigt?

Die VM die das Image benutzt lief zu dem Zeitpunkt.

>> Bei rotierendem Rost ist discard irrelevant, richtig?
>
>Ja. Es könnte noch bei SMR-Platten wichtig/interessant sein, aber da
>fehlen mir die Infos.

Klingt sinnvoll. Bei sda, das ist rotierender Rost, steht überall
"0B".

>> Auf dem Notebook, das diese Operation noch nicht hinter sich hat (und
>> btrfs verwendet), sieht lsblk --discard so aus:
>
>> |NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
>> |sda 0 4K 2G 0
>> |+-sda1 3072 4K 2G 0
>> |+-sda2 0 4K 2G 0
>> |+-sda3 0 4K 2G 0
>> | +-drop-c_boot 0 4K 2G 0
>> | ¦ +-boot 0 0B 0B 0
>> | +-drop-c_swap0 0 4K 2G 0
>> | ¦ +-swap0 0 0B 0B 0
>> | +-drop-c_dropbtr0 0 4K 2G 0
>> | ¦ +-dropbtr0 0 0B 0B 0
>
>> Was ist mit discard für swap? Sinnvoll? Unnötig? Kontraproduktiv?
>
>Schon nötig, würde ich sagen. Der Platz der auslagerten und wieder
>eingelagerten Daten will man ja schon dem SSD-Controller mitteilen,
>damit dieser nicht unnötig verwaiste Speicherseiten von vor 2 Wochen
>noch hin- und herschiebt.


Und wenn man den Bereich im Swapspace dann wieder verwendet wird ein
neuer Bereich der SSD allokiert?

Sven Hartge

unread,
Apr 5, 2022, 5:40:09 AM4/5/22
to
Das könnte natürlich auch ein Grund sein, LV ist gelockt.

>>> Bei rotierendem Rost ist discard irrelevant, richtig?
>
>> Ja. Es könnte noch bei SMR-Platten wichtig/interessant sein, aber da
>> fehlen mir die Infos.

> Klingt sinnvoll. Bei sda, das ist rotierender Rost, steht überall
> "0B".

Alle Datenträger, bei denen jeder Block direkt und ohne Einflussnahme
von umliegenden Blöcke beschrieben werden kann, brauchen kein TRIM.

Also normale HDDs und auch Intel Optane Speicher.

SMR HDDs können davon profitieren, weil dort Sektoren nicht direkt ohne
Lesen und Neuschreiben der anderen Sektoren in der gleichen Zone (oder
Schindel) verändert werden können, analog zum Erase Block bei Flash.

>>> Auf dem Notebook, das diese Operation noch nicht hinter sich hat (und
>>> btrfs verwendet), sieht lsblk --discard so aus:
>>
>>> |NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
>>> |sda 0 4K 2G 0
>>> |+-sda1 3072 4K 2G 0
>>> |+-sda2 0 4K 2G 0
>>> |+-sda3 0 4K 2G 0
>>> | +-drop-c_boot 0 4K 2G 0
>>> | ¦ +-boot 0 0B 0B 0
>>> | +-drop-c_swap0 0 4K 2G 0
>>> | ¦ +-swap0 0 0B 0B 0
>>> | +-drop-c_dropbtr0 0 4K 2G 0
>>> | ¦ +-dropbtr0 0 0B 0B 0
>>
>>> Was ist mit discard für swap? Sinnvoll? Unnötig? Kontraproduktiv?
>>
>> Schon nötig, würde ich sagen. Der Platz der auslagerten und wieder
>> eingelagerten Daten will man ja schon dem SSD-Controller mitteilen,
>> damit dieser nicht unnötig verwaiste Speicherseiten von vor 2 Wochen
>> noch hin- und herschiebt.

> Und wenn man den Bereich im Swapspace dann wieder verwendet wird ein
> neuer Bereich der SSD allokiert?

Who knows! Das ist die interne und geheime Magie im Translation-Layer
des Flash-Controllers, wie genau er die externen LBAs auf die internen
Flash-Zellen mappt.

Deswegen machen wir ja die ganze TRIM-Geschichte, um dem Controller
Infos darüber zu geben, welche Daten nicht mehr benötigt werden.

Was der Controller selbst damit macht? Magic!

Ich bilde mir ein, das mkswap bei Devices mit verfügbarem TRIM/DISCARD
vor der Erzeugung erst einmal ein Discard für das komplette zukünftige
Swap-Device sendet, um dem Controller mitzuteilen das alle bestehenden
Daten weg können. [citation needed]

Sieghard Schicktanz

unread,
Apr 5, 2022, 2:13:06 PM4/5/22
to
Hallo Sven Hartge,

Du schriebst am Tue, 5 Apr 2022 11:40:08 +0200:

> Alle Datenträger, bei denen jeder Block direkt und ohne Einflussnahme
> von umliegenden Blöcke beschrieben werden kann, brauchen kein TRIM.

Da fehlt noch ein Kriterium: Wenn die Blöcke auch nicht laufend für
Ersatzzwecke und Umschichtungen gebraucht werden - was halt bei Flash-
Medien grundsätzlich der Fall ist.

> Also normale HDDs und auch Intel Optane Speicher.

Bei letzteren wäre ich skeptisch - das sind doch auch Hlbleiterpeicher?

...
> >>> Was ist mit discard für swap? Sinnvoll? Unnötig? Kontraproduktiv?
> >>
> >> Schon nötig, würde ich sagen. Der Platz der auslagerten und wieder

Sicher nötig - schließlich soll ja damit nicht der gesamte Bereich
vollgemüllt werden, im Gegenteil soll der Bereich möglichst bald wieder
für andere Zwecke verfügbar sein. Aber swap auf SSD ist sowieso eher
eine schlechte Idee, weil da ja ständig ein- und ausgelagert wird und
damit die Löschzyklenanzahl für die Chips unnötig hochgetrieben wird.
...
> > Und wenn man den Bereich im Swapspace dann wieder verwendet wird ein
> > neuer Bereich der SSD allokiert?

Ja, wenn der nicht per "TRIM" als wieder verfügbar gemeldet wird. Und
sogar dann kann der Controller entscheiden, daß der alte Platz schon
genügend Zyklen hinter sich gebracht hat und dzf. ein anderer, weniger
abgenudelter herhalten sollte.

> Who knows! Das ist die interne und geheime Magie im Translation-Layer
> des Flash-Controllers, wie genau er die externen LBAs auf die internen
> Flash-Zellen mappt.

Das hat nur recht bedingt mit dem Block-Mapping zu tun, das ist
wesentlich von der Schreib-Lösch-Zyklenzahl bestimmt. Die ist bei
diesen Chips halt - teils recht eng - begrenzt, im Gegensatz zu den
magnetischen Datenträgern.

Marc Haber

unread,
Apr 5, 2022, 2:59:57 PM4/5/22
to
Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>Aber swap auf SSD ist sowieso eher
>eine schlechte Idee, weil da ja ständig ein- und ausgelagert wird und
>damit die Löschzyklenanzahl für die Chips unnötig hochgetrieben wird.

Die SSD ist dafür da dass man sie benutzt. Speicher ist immer zu wenig
und zu langsam. Wenn Swap, dann auf den schnellsten Massenspeicher den
man hat.

Ulli Horlacher

unread,
Apr 6, 2022, 4:29:32 AM4/6/22
to
Sven Hartge <sh-...@svenhartge.de> wrote:

> Ich bilde mir ein, das mkswap bei Devices mit verfügbarem TRIM/DISCARD
> vor der Erzeugung erst einmal ein Discard für das komplette zukünftige
> Swap-Device sendet, um dem Controller mitzuteilen das alle bestehenden
> Daten weg können. [citation needed]

https://wiki.ubuntuusers.de/SSD/TRIM/#TRIM-der-Swap-Partition

"führt Swapon beim ersten Start des Swap einen Discard aus"

Dazu fehlt mir aber auch eine Original-Quelle. In der man-page steht
nichts dazu.

Laurenz Trossel

unread,
Apr 6, 2022, 6:30:48 AM4/6/22
to
On 2022-04-06, Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> "führt Swapon beim ersten Start des Swap einen Discard aus"
>
> Dazu fehlt mir aber auch eine Original-Quelle. In der man-page steht
> nichts dazu.

Bei mir schon. Aus swapon(8):

-d, --discard[=policy]
[...]
--discard=once to perform a single-time discard operation for the whole
swap area at swapon; or --discard=pages to asynchronously discard freed
swap pages before they are available for reuse. If no policy is selected,
the default behavior is to enable both discard types.

Ulli Horlacher

unread,
Apr 6, 2022, 7:49:20 AM4/6/22
to
Ich hab noch eine ZUSATZFRAGE:

Wieso wird bei direkt aufeinanderfolgenden TRIMs immer wieder Speicher freigegeben?


root@moep:/usb/ST5_1# df -H .
Filesystem Size Used Avail Use% Mounted on
/dev/sdd1 35G 4.0G 31G 12% /usb/ST5_1

root@moep:/usb/ST5_1# lsblk --discard /dev/sdd1
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdd1 0 512B 4G 0

root@moep:/usb/ST5_1# fstrim -v .
.: 28.3 GiB (30405955584 bytes) trimmed

root@moep:/usb/ST5_1# fstrim -v .
.: 858.1 MiB (899780608 bytes) trimmed

root@moep:/usb/ST5_1# fstrim -v .
.: 858.1 MiB (899780608 bytes) trimmed

Sieghard Schicktanz

unread,
Apr 6, 2022, 2:13:05 PM4/6/22
to
Hallo Marc Haber,

Du schriebst am Tue, 05 Apr 2022 20:59:55 +0200:

> >Aber swap auf SSD ist sowieso eher
> >eine schlechte Idee, weil da ja ständig ein- und ausgelagert wird und
...
> Die SSD ist dafür da dass man sie benutzt. Speicher ist immer zu wenig
> und zu langsam. Wenn Swap, dann auf den schnellsten Massenspeicher den
> man hat.

Es soll Leute geben, die auch die Lebensdauer ihrer Geräte in Betracht
ziehen. Undes soll auch Anwendungen geben, bei denen die Lebensdauer
der Geräte, und manchmal sogar der Daten, relevant ist.
Dessen ungeachtet ist es jedem unbenommen, mit seinen Geräten zu
verfahren, wie er es für nötig und nützlich hält.

Sven Hartge

unread,
Apr 6, 2022, 2:27:37 PM4/6/22
to
Sieghard Schicktanz <Sieghard....@schs.de> wrote:
> Hallo Marc Haber, Du schriebst am Tue, 05 Apr 2022 20:59:55 +0200:

>>> Aber swap auf SSD ist sowieso eher eine schlechte Idee, weil da ja
>>> ständig ein- und ausgelagert wird und

>> Die SSD ist dafür da dass man sie benutzt. Speicher ist immer zu
>> wenig und zu langsam. Wenn Swap, dann auf den schnellsten
>> Massenspeicher den man hat.

> Es soll Leute geben, die auch die Lebensdauer ihrer Geräte in Betracht
> ziehen. Undes soll auch Anwendungen geben, bei denen die Lebensdauer
> der Geräte, und manchmal sogar der Daten, relevant ist.

Sofern deine SSD nicht von 2005 ist, wirst du eine aktuelle SSD auch mit
brutalster Schreiblast nicht in einem normalen Zeitraum kaputt bekommen.

Und selbst bei hoher (aber normaler) Nutzung wird eine normale
Consumer-SSD das Gerät, in dem sie steckt, locker um das doppelte
überleben.

SSDs wie rohe Eier zu behandeln und bloß jedes geschriebene Byte von
ihnen fernzuhalten ist ein Unsinn und ein Mythos aus lang vergangenen
IT-Zeiten.

Sven Hartge

unread,
Apr 6, 2022, 2:39:13 PM4/6/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:

>> Ich bilde mir ein, das mkswap bei Devices mit verfügbarem TRIM/DISCARD
>> vor der Erzeugung erst einmal ein Discard für das komplette zukünftige
>> Swap-Device sendet, um dem Controller mitzuteilen das alle bestehenden
>> Daten weg können. [citation needed]

> https://wiki.ubuntuusers.de/SSD/TRIM/#TRIM-der-Swap-Partition

> "führt Swapon beim ersten Start des Swap einen Discard aus"

> Dazu fehlt mir aber auch eine Original-Quelle. In der man-page steht
> nichts dazu.

Aus swapon(8) von util-linux 2.37.3:

,----
| -d, --discard[=policy]
| Enable swap discards, if the swap backing device supports
| the discard or trim operation. This may improve
| performance on some Solid State Devices, but often it
| does not. The option allows one to select between two
| available swap discard policies:
|
| --discard=once
| to perform a single-time discard operation for the
| whole swap area at swapon; or
|
| --discard=pages
| to asynchronously discard freed swap pages before
| they are available for reuse.
|
| If no policy is selected, the default behavior is to
| enable both discard types. The /etc/fstab mount options
| discard, discard=once, or discard=pages may also be used
| to enable discard flags.
`----

Wobei der Code zum TRIMmen dann im Kernel steckt, swapon selbst setzt
nur die Flags:

,----[ sys-utils/swapon.c
| 663 if (prop->discard && !(prop->discard & ~SWAP_FLAGS_DISCARD_VALID)) {
| 664 /*
| 665 * If we get here with both discard policy flags set,
| 666 * we just need to tell the kernel to enable discards
| 667 * and it will do correctly, just as we expect.
| 668 */
| 669 if ((prop->discard & SWAP_FLAG_DISCARD_ONCE) &&
| 670 (prop->discard & SWAP_FLAG_DISCARD_PAGES))
| 671 flags |= SWAP_FLAG_DISCARD;
| 672 else
| 673 flags |= prop->discard;
| 674 }
`----

mkswap selbst beinhaltet keinen Code, der den FITRIM ioctl ausführt. Der
ist nur im fstrim-Code zu finden.

Arno Lutz

unread,
Apr 6, 2022, 2:41:17 PM4/6/22
to
Am 06.04.22 um 20:27 schrieb Sven Hartge:
> Sofern deine SSD nicht von 2005 ist, wirst du eine aktuelle SSD auch mit
> brutalster Schreiblast nicht in einem normalen Zeitraum kaputt bekommen.

*normaler Zeitraum* ist (bei dir) definiert wie folgt:
.....


Arno

Sieghard Schicktanz

unread,
Apr 6, 2022, 4:13:05 PM4/6/22
to
Hallo Laurenz Trossel,

Du schriebst am Wed, 6 Apr 2022 10:30:47 -0000 (UTC):

> Bei mir schon. Aus swapon(8):
>
> -d, --discard[=policy]
> [...]
> --discard=once to perform a single-time discard operation for the
> whole swap area at swapon; or --discard=pages to asynchronously
> discard freed swap pages before they are available for reuse. If no
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> policy is selected, the default behavior is to enable both discard
> types.

Steht das _wirklich_ _so_ da? D.h. die Seiten werden freigeeben,
_bevor_ sie wiederbenutzt werden können, d.h. während sie noch in
Benutzung sind? Das wäre ja fatal .

Marc Haber

unread,
Apr 6, 2022, 4:27:41 PM4/6/22
to
Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>Es soll Leute geben, die auch die Lebensdauer ihrer Geräte in Betracht
>ziehen. Undes soll auch Anwendungen geben, bei denen die Lebensdauer
>der Geräte, und manchmal sogar der Daten, relevant ist.

Dann sollte man die SSD in Originalverpackung in den Schrank legen,
dann hält sie so gut wie ewig.

Clemens Schüller

unread,
Apr 6, 2022, 4:44:53 PM4/6/22
to
Servus!

Marc Haber schrieb am 06. Apr. 2022 um 22:27:
> Sieghard Schicktanz <Sieghard....@SchS.de> wrote:


>>Es soll Leute geben, die auch die Lebensdauer ihrer Geräte in Betracht
>>ziehen. Undes soll auch Anwendungen geben, bei denen die Lebensdauer
>>der Geräte, und manchmal sogar der Daten, relevant ist.
>
> Dann sollte man die SSD in Originalverpackung in den Schrank legen,
> dann hält sie so gut wie ewig.

Ich kenn da jemanden, dessen Raspi über ein Jahr OVP im Schrank gelegen
hat :-D


--
LieGrü aus Graz, Clemens

Thomas Klix

unread,
Apr 6, 2022, 6:32:15 PM4/6/22
to
Sieghard Schicktanz wrote at Wed, 6 Apr 2022 20:10:28 +0200:
> Hallo Marc Haber,
>
> Du schriebst am Tue, 05 Apr 2022 20:59:55 +0200:
>
>> >Aber swap auf SSD ist sowieso eher
>> >eine schlechte Idee, weil da ja ständig ein- und ausgelagert wird und
> ...
>> Die SSD ist dafür da dass man sie benutzt. Speicher ist immer zu wenig
>> und zu langsam. Wenn Swap, dann auf den schnellsten Massenspeicher den
>> man hat.
>
> Es soll Leute geben, die auch die Lebensdauer ihrer Geräte in Betracht
> ziehen.

Eine SSD hat in den letzten Jahr(zehnt)en heftig an Lebenserwartung
zugenommen. Alte Weisheiten gelten da nicht mehr (unbedingt).
Man kann natürlich auch 7-10 Jahre swap auf schnarchigen HDDs akzeptieren,
statt mal eine (heutzutage tatsächlich preiswerte) SSD zu ersetzen.

> Undes soll auch Anwendungen geben, bei denen die Lebensdauer
> der Geräte,

Hatten wir das nicht gerade?

> und manchmal sogar der Daten, relevant ist.

Jede Festplatte kann ausfallen, ob HD oder SSD, ob viel oder wenig genutzt.
Wer kein Backup macht, ist... na?

> Dessen ungeachtet ist es jedem unbenommen, mit seinen Geräten zu
> verfahren, wie er es für nötig und nützlich hält.

Eben.

Thomas

Marc Haber

unread,
Apr 7, 2022, 1:47:56 AM4/7/22
to
So einen kenn ich auch. Ich kenne auch einen, der zwei Raspis seit
über einem halben Jahr auf dem Elektroniktisch liegen hat, weil er
darauf wartet, dass man auch ein UEFI-gebootetes Linux endlich mit
grafischer Oberfläche betreiben kann.

Im Moment denke ich ja eher darüber nach die Dinger auf dem Spotmarkt
zu verkaufen, die Preise haben sich sei Herbst nahezu verdreifacht.

Grüße
Marc

Laurenz Trossel

unread,
Apr 7, 2022, 3:33:22 AM4/7/22
to
On 2022-04-06, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:

>> discard freed swap pages before they are available for reuse. If no
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Steht das _wirklich_ _so_ da? D.h. die Seiten werden freigeeben,
> _bevor_ sie wiederbenutzt werden können, d.h. während sie noch in
> Benutzung sind? Das wäre ja fatal .

Du interpretierst den Satz falsch. Dort steht nicht, daß die Seiten noch in
Benutzung wären. Hast du das "freed swap pages" überlesen?

Ralph Angenendt

unread,
Apr 7, 2022, 6:18:10 AM4/7/22
to
Haltbarer als drehender Rost.

Man muss also bei SSDs genau so wenig kaputt bekommen wie bei einer
Festplatte, und da macht ja auch niemand Klimmzüge und schreibt seine
Logs auf Papier weg, damit die Festplatte länger hält.

Ralph
--
Übervaterlandverräter und Mutterkornblumenblau

Ralph Angenendt

unread,
Apr 7, 2022, 8:12:44 AM4/7/22
to
Well, Arno Lutz <inv...@freakmail.de> wrote:
Haltbarer als drehender Rost.

Man kann also bei modernen SSDs genau so wenig kaputt bekommen wie bei

Ulli Horlacher

unread,
Apr 7, 2022, 8:38:06 AM4/7/22
to
Sven Hartge <sh-...@svenhartge.de> wrote:

> > https://wiki.ubuntuusers.de/SSD/TRIM/#TRIM-der-Swap-Partition
>
> > "führt Swapon beim ersten Start des Swap einen Discard aus"
>
> > Dazu fehlt mir aber auch eine Original-Quelle. In der man-page steht
> > nichts dazu.
>
> Aus swapon(8) von util-linux 2.37.3:
>
> ,----
> | -d, --discard[=policy]
> | Enable swap discards, if the swap backing device supports
> | the discard or trim operation. This may improve
> | performance on some Solid State Devices, but often it
> | does not. The option allows one to select between two
> | available swap discard policies:
> |
> | --discard=once
> | to perform a single-time discard operation for the
> | whole swap area at swapon; or
> |
> | --discard=pages
> | to asynchronously discard freed swap pages before
> | they are available for reuse.
> |
> | If no policy is selected, the default behavior is to
> | enable both discard types. The /etc/fstab mount options
> | discard, discard=once, or discard=pages may also be used
> | to enable discard flags.

Wenn man also swapon ohne --discard aufruft wird kein TRIM gemacht?

Was nicht klar draus hervorgeht, ist was passiert, wenn in der fstab gar
kein discard option angegeben ist.

Also besser sw,discard=once in /etc/fstab schreiben?

Diedrich Ehlerding

unread,
Apr 7, 2022, 8:52:08 AM4/7/22
to
Ulli Horlacher meinte:

>> |If no policy is selected, the default behavior is to
^^^^^^^^^^^^^^^^
>> |enable both discard types. The /etc/fstab mount options
^^^^^^^^^^^^^^^^^^^^^^^^^
>> |discard, discard=once, or discard=pages may also be used
>> |to enable discard flags.
>
> Wenn man also swapon ohne --discard aufruft wird kein TRIM gemacht?
>
> Was nicht klar draus hervorgeht, ist was passiert, wenn in der fstab
> gar kein discard option angegeben ist.

Ich lese da oben was von "default policy".
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

Ulli Horlacher

unread,
Apr 7, 2022, 9:00:41 AM4/7/22
to
Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Ulli Horlacher meinte:
>
> >> |If no policy is selected, the default behavior is to
> ^^^^^^^^^^^^^^^^
> >> |enable both discard types. The /etc/fstab mount options
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> >> |discard, discard=once, or discard=pages may also be used
> >> |to enable discard flags.
> >
> > Wenn man also swapon ohne --discard aufruft wird kein TRIM gemacht?
> >
> > Was nicht klar draus hervorgeht, ist was passiert, wenn in der fstab
> > gar kein discard option angegeben ist.
>
> Ich lese da oben was von "default policy".

Du hast das Wesentliche geloescht:
Das war ein Zitat aus der swapon man-page, ich hab aber zu /etc/fstab
gefragt. Letzteres wird direkt von systemd ausgewertet unter Umgehung von
swapon.

Thomas Dorner

unread,
Apr 7, 2022, 1:08:08 PM4/7/22
to
Diedrich Ehlerding <diedrich....@t-online.de> writes:

> Ulli Horlacher meinte:
>
>>> |If no policy is selected, the default behavior is to
> ^^^^^^^^^^^^^^^^
>>> |enable both discard types. The /etc/fstab mount options
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>>> |discard, discard=once, or discard=pages may also be used
>>> |to enable discard flags.
>>
>> Wenn man also swapon ohne --discard aufruft wird kein TRIM gemacht?
>>
>> Was nicht klar draus hervorgeht, ist was passiert, wenn in der fstab
>> gar kein discard option angegeben ist.
>
> Ich lese da oben was von "default policy".

Ich lese:
default policy wenn --discard ohne die optionale policy verwendet wird.

| --discard[=policy]

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

Gerald E¡scher

unread,
Apr 7, 2022, 3:24:34 PM4/7/22
to
Ulli Horlacher schrieb am 7/4/2022 15:00:

> Das war ein Zitat aus der swapon man-page, ich hab aber zu /etc/fstab
> gefragt. Letzteres wird direkt von systemd ausgewertet unter Umgehung von
> swapon.

man fstab verweist bezüglich der mount options unter "The fourth field"
auf mount(8) oder swapon(8).

Von daher würde ich meinen, wenn in der /etc/fstab bei swap kein
discard steht, dann wird die Swap-Partition nicht geTRIMt.

--
Gerald

Sven Hartge

unread,
Apr 8, 2022, 1:25:12 AM4/8/22
to
5 Jahre. Aber niemand befeuert eine SSD/NVME 24/7 mit der maximalen
Bandbreite, die möglich ist. Dies ist aber nötig, um eine solche
mutwillig zu zerstören.

Sven Hartge

unread,
Apr 8, 2022, 1:27:19 AM4/8/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Diedrich Ehlerding <diedrich....@t-online.de> wrote:
>> Ulli Horlacher meinte:

>> >> |If no policy is selected, the default behavior is to
>> ^^^^^^^^^^^^^^^^
>> >> |enable both discard types. The /etc/fstab mount options
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> |discard, discard=once, or discard=pages may also be used
>> >> |to enable discard flags.
>> >
>> > Wenn man also swapon ohne --discard aufruft wird kein TRIM gemacht?
>> >
>> > Was nicht klar draus hervorgeht, ist was passiert, wenn in der fstab
>> > gar kein discard option angegeben ist.
>>
>> Ich lese da oben was von "default policy".

> Du hast das Wesentliche geloescht:
> Das war ein Zitat aus der swapon man-page, ich hab aber zu /etc/fstab
> gefragt. Letzteres wird direkt von systemd ausgewertet unter Umgehung von
> swapon.

In den Source von systemd möge jemand anderes schauen. Dürfte aber
einfach zu finden sein, wenn man den Code aus swapon.c als Beispiel
nimmt.

Sven Hartge

unread,
Apr 8, 2022, 1:30:08 AM4/8/22
to
Sieghard Schicktanz <Sieghard....@schs.de> wrote:
> Hallo Laurenz Trossel, Du schriebst am Wed, 6 Apr 2022 10:30:47 -0000 (UTC):

>> Bei mir schon. Aus swapon(8):
>>
>> -d, --discard[=policy]
>> [...]
>> --discard=once to perform a single-time discard operation for the
>> whole swap area at swapon; or --discard=pages to asynchronously
>> discard freed swap pages before they are available for reuse. If no
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> policy is selected, the default behavior is to enable both discard
>> types.

> Steht das _wirklich_ _so_ da? D.h. die Seiten werden freigeeben,
> _bevor_ sie wiederbenutzt werden können, d.h. während sie noch in
> Benutzung sind? Das wäre ja fatal .

Der wichtige Punkt ist aber: "freed swap", beachte die
Vergangenheitsform.

Also swap pages, die bereits freigegeben sind, werden geTRIMt, bevor sie
neu benutzt werden können.

Hermann Riemann

unread,
Apr 8, 2022, 6:30:12 AM4/8/22
to
Am 06.04.22 um 20:27 schrieb Sven Hartge:

> Sofern deine SSD nicht von 2005 ist, wirst du eine aktuelle SSD auch mit
> brutalster Schreiblast nicht in einem normalen Zeitraum kaputt bekommen.

Getestet?

Testempfehlung mit einem raspberry pi, der sonst nichts macht:
Leere partition so groß wie die SSD.
Mit ext4 formatieren und mit mount verbinden

In einer Schleife
rm -r *
open(dateinname,"w")
schreiben bis Fehlermeldung:
Schreiben von 4k Blöcke mit allen Bits auf 1 gesetzt (0xFF..
jedesmal flash, damit es auch geschrieben wird
dann close()
rm dateiname
open(dateinname,"w")
schreiben bis Fehlermeldung:
Schreiben von 4k Blöcke mit allen Bits auf 0 gesetzt (0x0..
jedesmal flash, damit es auch geschrieben wird
dann close()

Hermann
vermutend, dass man damit noch die Grenze erreicht.

--
http://www.hermann-riemann.de

Christoph 'Mehdorn' Weber

unread,
Apr 9, 2022, 10:30:18 AM4/9/22
to
Hallo!

* Ulli Horlacher <fram...@rus.uni-stuttgart.de>:

> Ich bin doch nicht der erste, der so was braucht?
> Gibts da nix fertiges?

Wenn du sie immer an dieselbe Stelle mountest, käme sicher was
mit "path-based activation" infrage, siehe systemd.path(5). Die
startet dir dann einfach fstrim.service, wenn das Dateisystem
eingebunden wird.

>> (z.B. über Nutzungsdaten aus smartctl)
> SMART bietet keine Nutzungshistorie.

Bei mir legt es in /var/lib/smartmontools/ für jede Platte
regelmäßig eine Datei "<model>-<serial>.<anschluss>.state" ab,
und bewahrt die ältere Version als "state~" auf. Vermutlich muß
man dafür aber "DEVICESCAN" für alle in smartd.conf einschalten.
Aber darüber könnte man zumindest abschätzen, wenn die Platte
länger nicht am System war.

Christoph

--
Junger Yedi du bist. Noch viel lernen du musst.
Erster Satz der Systemadministration so geht:
"Ich bin root, ich darf das."
(Lukas Schratz)

Ulli Horlacher

unread,
Apr 15, 2022, 3:57:52 AM4/15/22
to
fstrim geht anscheinend nicht bei mdadm RAID :

root@juhu:~# lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 4K 32M 0
|-sda1 0 4K 32M 0
|-sda2 0 4K 32M 0
|-sda3 0 4K 32M 0
`-sda4 0 4K 32M 0
`-md127 0 2M 32M 0
sdb 0 4K 32M 0
|-sdb1 0 4K 32M 0
|-sdb2 0 4K 32M 0
|-sdb3 0 4K 32M 0
`-sdb4 0 4K 32M 0
`-md127 0 2M 32M 0
sdc 0 4K 32M 0
|-sdc1 0 4K 32M 0
|-sdc2 0 4K 32M 0
|-sdc3 0 4K 32M 0
`-sdc4 0 4K 32M 0
`-md127 0 2M 32M 0
sdd 0 4K 32M 0
|-sdd1 0 4K 32M 0
|-sdd2 0 4K 32M 0
|-sdd3 0 4K 32M 0
`-sdd4 0 4K 32M 0
`-md127 0 2M 32M 0

root@juhu:~# mount | grep ^/dev
/dev/sda1 on / type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
/dev/md127 on /local type btrfs (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

root@juhu:~# fstrim -v /local
fstrim: /local: the discard operation is not supported

root@juhu:~# mdadm --detail /dev/md127
/dev/md127:
Version : 1.2
Creation Time : Thu Feb 10 09:38:22 2022
Raid Level : raid5
Array Size : 4285387776 (4086.86 GiB 4388.24 GB)
Used Dev Size : 1428462592 (1362.29 GiB 1462.75 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Fri Apr 15 09:55:37 2022
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 512K

Consistency Policy : bitmap

Name : mux:nts1
UUID : 74388db3:3c3b30c3:e1295cc5:46f23ff7
Events : 1241

Number Major Minor RaidDevice State
0 8 20 0 active sync /dev/sdb4
1 8 4 1 active sync /dev/sda4
2 8 52 2 active sync /dev/sdd4
4 8 36 3 active sync /dev/sdc4

Sven Hartge

unread,
Apr 15, 2022, 5:56:53 AM4/15/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

> fstrim geht anscheinend nicht bei mdadm RAID :

Funktioniert bei mir. Habe ich erst gestern gemacht.

Neuer Dell R440 mit zwei 120TB SSDs im RAID1 via MD und LVM oben drauf.
fstrim hat ohne Probleme funktioniert.
Was sagt das Kernel-Log, wenn das RAID zusammengebaut wird und wenn es
gemounted wird?

Ist das vielleicht nur eine Eigenart von BTRFS auf MD-RAID?

Weil ext4-auf-LVM-auf-MD trimmt ohne Probleme.

Martin Reising

unread,
Apr 15, 2022, 7:42:09 AM4/15/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> root@juhu:~# mdadm --detail /dev/md127
> /dev/md127:
> Version : 1.2
> Creation Time : Thu Feb 10 09:38:22 2022
> Raid Level : raid5

Für RAID 5 muß man dem Kernel Modul raid456 mit der Option

devices_handle_discard_safely=Y

mitteilen das Discard "sicher" ist.

Läuft seit Dezember 2021 mit 3 x 1T

/dev/disk/by-id/nvme-KXG60ZNV1T02_TOSHIBA*

cat /etc/modprobe.d/raid456.conf
# https://forum.openmediavault.org/index.php?thread/25923-what-i-learnt-regarding-ssd-trim-and-mdadm-raid5-lvm-ext4/
# https://current.workingdirectory.net/posts/2016/ssd-discard/
# https://bugzilla.redhat.com/show_bug.cgi?id=1307091
options raid456 devices_handle_discard_safely=Y

unauffällig.

Ulli Horlacher

unread,
Apr 15, 2022, 1:51:37 PM4/15/22
to
2022-04-10 07:32:59 [ 10.156576] md/raid:md127: device sdb4 operational as raid disk 0
2022-04-10 07:32:59 [ 10.156595] md/raid:md127: device sda4 operational as raid disk 1
2022-04-10 07:32:59 [ 10.156612] md/raid:md127: device sdc4 operational as raid disk 3
2022-04-10 07:32:59 [ 10.156628] md/raid:md127: device sdd4 operational as raid disk 2
2022-04-10 07:32:59 [ 10.157074] md/raid:md127: raid level 5 active with 4 out of 4 devices, algorithm 2
2022-04-10 07:32:59 [ 10.157439] md127: detected capacity change from 0 to 4388237082624
2022-04-10 07:32:59 [ 10.864771] BTRFS: device label local devid 1 transid 18660 /dev/md127


> Ist das vielleicht nur eine Eigenart von BTRFS auf MD-RAID?
>
> Weil ext4-auf-LVM-auf-MD trimmt ohne Probleme.

Kann ich leider nicht umformtieren, zu viel Daten drauf.

Ohne mdadm funktionierts:

root@juhu:~# fstrim -v /
/: 8 GiB (8549412864 bytes) trimmed

Ulli Horlacher

unread,
Apr 15, 2022, 5:05:52 PM4/15/22
to
Unauffaellig ist es bei mir nicht grad:

Ich hab das wie oben bei mir eingetragen, dann:

root@juhu:~# update-initramfs -u
root@juhu:~# reboot
(...)
root@juhu:~# cat /sys/module/raid456/parameters/devices_handle_discard_safely
Y
root@juhu:~# fstrim -v /local
/local: 2.7 TiB (2907136225280 bytes) trimmed

Ich musste 15 Minuten warten bis ich wieder einen prompt hatte und alle
Zugriffe auf /local (wo auch /home liegt) fuehrten zum Einfrieren des
Prozess, also auch neue xterms.
Ich war kurz davor nochmal zu rebooten, zumal ich keinerlei Fortschritt sah.

So... nochmal:

root@juhu:~# time fstrim -v /local
/local: 59.7 GiB (64034230272 bytes) trimmed

real 0m21.843s
user 0m0.000s
sys 0m7.027s


Ich bin nun unschluessig, ob ich den systemd timer behalten soll:

root@juhu:~# systemctl cat fstrim.timer
# /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target


Wenn der unvermittelt zuschlaegt friert mir das System bis zu 15 Minuten
ein. Weiss ich dann noch, was los ist? Will ich das?

Sven Hartge

unread,
Apr 15, 2022, 10:18:32 PM4/15/22
to
Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Sven Hartge <sh-...@svenhartge.de> wrote:

>>> root@juhu:~# fstrim -v /local
>>> fstrim: /local: the discard operation is not supported
>>
>> Was sagt das Kernel-Log, wenn das RAID zusammengebaut wird und wenn es
>> gemounted wird?

> 2022-04-10 07:32:59 [ 10.156576] md/raid:md127: device sdb4 operational as raid disk 0
> 2022-04-10 07:32:59 [ 10.156595] md/raid:md127: device sda4 operational as raid disk 1
> 2022-04-10 07:32:59 [ 10.156612] md/raid:md127: device sdc4 operational as raid disk 3
> 2022-04-10 07:32:59 [ 10.156628] md/raid:md127: device sdd4 operational as raid disk 2
> 2022-04-10 07:32:59 [ 10.157074] md/raid:md127: raid level 5 active with 4 out of 4 devices, algorithm 2
> 2022-04-10 07:32:59 [ 10.157439] md127: detected capacity change from 0 to 4388237082624
> 2022-04-10 07:32:59 [ 10.864771] BTRFS: device label local devid 1 transid 18660 /dev/md127

Hmmtja, wenig Aussagekraft hier.

>> Ist das vielleicht nur eine Eigenart von BTRFS auf MD-RAID?
>>
>> Weil ext4-auf-LVM-auf-MD trimmt ohne Probleme.

> Kann ich leider nicht umformtieren, zu viel Daten drauf.

Ich vermute stark ein Problem bei BTRFS hier, denn mit ext4 oder XFS
funktioniert es ohne Zweifel auf MD oder gar auf LVM-auf-MD.

Sven Hartge

unread,
Apr 15, 2022, 10:20:13 PM4/15/22
to
Martin Reising <mreising+...@nixda.org> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:

>> root@juhu:~# mdadm --detail /dev/md127
>> /dev/md127:
>> Version : 1.2
>> Creation Time : Thu Feb 10 09:38:22 2022
>> Raid Level : raid5

> Für RAID 5 muß man dem Kernel Modul raid456 mit der Option

> devices_handle_discard_safely=Y

> mitteilen das Discard "sicher" ist.

Ahhh, das erklärt warum es bei mir immer funktioniert: Weil das immer
nur RAID1 ist.

Interessant.
0 new messages