[gelöst] LUKS Daten-SSD: TRIM

[mod3]

Hallo,

habe hier eine per cryptsetup verschlüsselte Daten-SSD in einem Server.
Diese würde ich natürlich ab und an gern TRIMmen.
Problem: Dazu muss man ja offenbar die /etc/crypttab bearbeiten.
Aber: Diese nutze ich nicht.
Denn der Server ist für mich fast nur per SSH zugänglich und so wird das LUKS-Passwort nach einem Reboot händisch an der SSH eingegeben.

Was kann ich tun? Die Daten jedes Mal woanders hin zu schaufeln, die SSD normal formatieren, TRIMmen, wieder verschlüsseln und dann die Daten zurückkopieren... das kann natürlich keine Dauerlösung sein

[rendegast]

Auf dem Datenträger sollte imo freier Platz gelassen werden, 10-20% laut krenn.

Modernere SSD sollten trim dann wohl selbständig erledigen können.

$ man hdparm | grep -i trim
--trim-sector-ranges
For Solid State Drives (SSDs). EXCEPTIONALLY DANGEROUS. DO NOT
USE THIS OPTION!! Tells the drive firmware to discard unneeded
data sectors, destroying any data that may have been present
within them. This makes those sectors available for immediate
use by the firmware's garbage collection mechanism, to improve
scheduling for wear-leveling of the flash media. This option
expects one or more sector range pairs immediately after the
option: an LBA starting address, a colon, and a sector count
(max 65535), with no intervening spaces. EXCEPTIONALLY DANGER‐
OUS. DO NOT USE THIS OPTION!!

E.g. hdparm --trim-sector-ranges 1000:4 7894:16 /dev/sdz

--trim-sector-ranges-stdin
Identical to --trim-sector-ranges above, except the list of
lba:count pairs is read from stdin rather than being specified
on the command line. This can be used to avoid problems with
excessively long command lines. It also permits batching of
many more sector ranges into single commands to the drive, up to
the currently configured transfer limit (max_sectors_kb).

Besser wohl

Code: Alles auswählen

$ dpkg-query -S blkdiscard 
util-linux: /sbin/blkdiscard
util-linux: /usr/share/man/man8/blkdiscard.8.gz

[Lord_Carlos]

Laut hier geht es wohl so:

cryptsetup luksOpen --allow-discards /dev/sdb test_disk

Ich habe das nur fix durchgelsen, bitte nochmal selber nachlesen.
Beachte das trim auch im filesytem und LVM zu aktiveren, das muss durch alle Lagen durchgereicht werden.

[mod3]

Danke!

Ein LVM ist hier nicht vorhanden. Es ist wirklich nur eine einfache, verschlüsselte SSD.
Nun, wenn ich --allow-discards nutze, bin ich doch fertig?
Denn danach rufe ich fstrim -v /mount/point/der/verschluesselten/ssd auf ?

[smutbert]

Eine SSD kann nur blockweise beschrieben werden und bevor ein Block beschrieben werden kann, muss er gelöscht werden. Blöcke können aber gar nicht einzeln gelöscht werden sondern nur in Gruppen (diese Gruppen heißen "erasable blocks").

Die garbage collection der SSD sorgt durch Umkopieren der Daten dafür, dass die freien Blöcke zu "erasable blocks" zusammengefasst und gelöscht werden, damit immer genug gelöschte Blöcke zum Beschreiben zur Verfüfung stehen - andernfalls würde die Performance beim Beschreiben ins Bodenlose absacken.
Hier hilft also ein ungenutzer Bereich auf der SSD, der dafür sorgt, dass die Garbage Collection genug freie Blöcke findet, die es durch Umkopieren der Daten zu einem "erasable block" zusammenfasst.

Das andere ist, aber, dass ohne echtes trim, bei dem die SSD von momentan durch das Dateisystem nicht genutzen Speicherbereichen erfährt, die garbage collection diesen Datenmüll ebenfalls mitkopieren muss, weil sie ihn nicht von wertvollen Daten unterscheiden kann. Fehlendes trim führt also zumindest theoretisch durchaus dazu, dass die Speicherzellen mehr Schreibzugriffe abbekommen und schneller verschleißen.
(Die Tatsache, dass hinter den Kulissen mehr Daten geschrieben werden, als eigentlich von Benutzer/Betriebssyste/Dateisystem erwartet wird und als es etwa bei Festplatten der Fall wäre, nennt man Write Amplification.)


Bei der Verschlüsselung ist halt auch so, dass allein dadurch, dass man verrät wo Daten gespeichert sind und welche Speicherbereiche ungenutzt sind, das Knacken der Verschlüsselung einfacher wird.

edit:
Ja, das --allow-discards sollte den gewünschten Effekt haben. Du kannst dann entweder fstrim aufrufen oder kannst das Dateisystem mit der Option discard mounten (nicht alle Dateisysteme können das, aber die meisten unter Linux üblichen schon) und dir den trim-Aufruf ersparen.

[rendegast]

Das andere ist, aber, dass ohne echtes trim, bei dem die SSD von momentan durch das Dateisystem nicht genutzen Speicherbereichen erfährt, die garbage collection diesen Datenmüll ebenfalls mitkopieren muss, weil sie ihn nicht von wertvollen Daten unterscheiden kann.

Aber hier habe ich ein Verständnisproblem.
Die Platte resp. deren firmware bekommt bei einem Schreibbefehl für einen Block,
den sie (nach Möglichkeit) auf einen "Ungenutzt"-Block umleitet,
doch mit, daß der vorherige Block nun "garbage" ist.

Bei einem verschlüsselten System hat imo zudem der Dateisystemtreiber damit gar nichts mehr zu tun,
denn selbst für das Dateisystem ungenutzte Blöcke sind doch tatsächlich mit Inhalt der Verschlüsselungsschicht beschrieben.




Zur Geschwindigkeit.
Ich habe hier Versuche gemacht mit einer 128GB Samsung 840Pro am SATA2,
Verschiedene Muster nacheinander auf das komplette(!) device geschrieben.
Für ein (platteninternes) trim bestand also gar kein Platz.
Dennoch war die Schreibleistung konstant (gut).
(Das Ding enthält noch eine gute Menge Speicher für trim, über den Nutzspeicher hinaus?)

[smutbert]

[…] Aber hier habe ich ein Verständnisproblem.
Die Platte resp. deren firmware bekommt bei einem Schreibbefehl für einen Block,
den sie (nach Möglichkeit) auf einen "Ungenutzt"-Block umleitet,
doch mit, daß der vorherige Block nun "garbage" ist.

Der Block (des Blockgeräts) bleibt derselbe - nur die Flashzellen werden ausgetauscht.

Dass die im Zuge des Schreibvorganges ersetzten Zellen nun keine genutzten Daten mehr enthalten weiß die SSD natürlich. Die so frei gewordenen Blöcke würde ich aber nicht mit dem, was man meistens mit trim/discard meint, in Verbindung bringen.

Bei einem verschlüsselten System hat imo zudem der Dateisystemtreiber damit gar nichts mehr zu tun,
denn selbst für das Dateisystem ungenutzte Blöcke sind doch tatsächlich mit Inhalt der Verschlüsselungsschicht beschrieben.

Aktiviert man trim/discard, dann werden die ungenutzten Speicherbereiche vom Dateisystem durch die Verschlüsselungsschicht hindurch an das zugrundeliegende Blockgerät weitergleitet.

Wie die SSD damit umgeht hängt wohl auch von der konkreten SSD und Firmware ab, aber generell werden die SSDs für so „getrimmte“ Bereiche beim Lesen nur noch Nullen liefern, selbst wenn die eigentlichen Flashzellen noch nicht gelöscht oder gar überschrieben worden sind.

Soweit ich weiß hat man genau dieses verhalten oft herangezogen um festzustellen ob trim/discard funktioniert. (Einen Block mit Daten beschrieben, dann den Bereich mittels trim als frei markiert und dann wieder gelesen und geschaut ob die Daten oder ob lauter 0 kommen.)

[…]
(Das Ding enthält noch eine gute Menge Speicher für trim, über den Nutzspeicher hinaus?)

Da bin ich mir so gut wie sicher.
Flashzellen werden auch gelegentlich kaputt und müssen ersetzt werden und ohne Reservespeicher/Overprovisioning würde eine SSD bei Schreibzugriffen zweifelsohne in die Knie gehen.

[mod3]

Nun, vielen Dank erstmal, mir ist geholfen!
Was mich ein wenig irritiert: Wenn ich dann ab und an mal trim von Hand aufrufe, ist er der Meinung, die gesamte jeweilige Partition geTRIMt zu haben.
Das ist aber Quatsch, so viele Daten wurden in der Zwischenzeit nämlich sicher nicht bewegt.

Woher kann's kommen?

[smutbert]

bin mir nicht sicher was genau du meinst, aber wenn man fstrim aufruft, markiert es einfach alle zusammenhängenden Speicherbereiche ab einer bestimmten Größe als frei, selbst wenn sie der SSD bereits als frei bekannt sind. Ruft man es also zwei Mal direkt hintereinander auf, sollte die Zahl der „getrimmten“ Bytes ungefähr gleich sein - ist es das was du meinst?

[mod3]

Hm, das klingt zwar sinnvoll, rufe ich es aber mehrfach hintereinander auf, gibt er ab dem 2. Durchlauf 0 Byte an:

Code: Alles auswählen

Server:~# fstrim -v /
/: 113,5 GiB (121812733952 bytes) trimmed
Server:~# fstrim -v /
/: 0 B (0 bytes) trimmed

[smutbert]

dann habe ich meine Erfahrungen zu sehr verallgemeinert - bei mir unter jessie

Code: Alles auswählen

# fstrim -v /
/: 340.3 GiB (365335805952 bytes) trimmed
# fstrim -v /
/: 340.1 GiB (365196435456 bytes) trimmed

allerdings bedeutet das auch, dass ich deine letzte Frage komplett falsch verstanden habe.

[mod3]

Ok, im Grunde ist das aber auch nicht weiter schlimm, solange die oben genannten Methoden dazu führen, dass "vernünftig" geTRIMt wird.

Danke euch!