zpool autotrim - Ist "off" ok

Wenn du TRIM nutzt sieht man auf jedenfall, welche Bereiche deiner SSD benutzt sind und welche nicht. Ich weiß nicht was das default bei geli ist, bei cryptsetup unter Linux ist TRIM default mäßig deaktiviert, geli hat ne Option aber kA ob das Default ist.
 
medV2 schrieb:
bei cryptsetup unter Linux ist TRIM default mäßig deaktiviert
Zum Vergrößern anklicken....
Bei der TRIM-Funktionalität geht es ja darum, der SSD mitzuteilen welche Blöcke frei sind, damit die die schon mal vorsorglich löschen kann, damit das nicht erst im Rahmen eines Schreibprozesses stattfindet.
Wenn ZFS direkt die SSD sieht, kann sie der natürlich hübsch mitteilen, welche Blöcke frei sind und welche nicht. Im Falle das da noch ne Krypto-Schicht drüber liegt, guckt ZFS nicht direkt auf die Disk, sondern aufs entsprechende Schicht.

Bei GELI ist es meines Wissens nach so implementiert, das man GELI das mitteilen kann und GELI kümmert sich dann darum, das an die unter liegende SSD durchzureichen.

Insofern ist das autotrim=off keine Folge des GELI-Setups. Die zugehörige Manpage verrät auch, das der Default-Wert off ist (und warum). Was ganz interessant ist, denn im ZFS-Code steht folgendes:
C: 
typedef enum {
    SPA_AUTOTRIM_OFF = 0,    /* default */
    SPA_AUTOTRIM_ON,
#ifdef IN_FREEBSD_BASE
    SPA_AUTOTRIM_DEFAULT = SPA_AUTOTRIM_ON,
#else
    SPA_AUTOTRIM_DEFAULT = SPA_AUTOTRIM_OFF,
#endif
Sprich: Wenn Teil von FreeBSD-Base, dann bitteschön als Default autotrim on.
Um das (auto)trim kümmern tut sich dann übrigens sys/contrib/openzfs/module/zfs/vdev_trim.c
 
Ich weiß, dass es geli kann, die frage ist, ob es default aktiviert ist. Wenn nein wären die ZFS Settings egal. Darauf wollte ich hinaus, vielleicht etwas kurz gefasst.
Cryptsetup bzw. luks kann es auch, da weiß ich aber, dass es per Default off ist. Und wenn ich etwas wie geli oder cryptsetup verwende, muss ich mir eben auch Gedanken machen, ob ich das will.
 
medV2 schrieb:
Ich weiß, dass es geli kann, die frage ist, ob es default aktiviert ist.
Zum Vergrößern anklicken....
Ist es seit einigen Versionen. Letztendlich ist die Frage halt, was einem wichtiger ist: Das die SSD gut funktioniert oder das ein Angreifer nicht abschätzen kann, wie viele Daten sich in der verschlüsselten Partition befinden. Bei mir ist es ganz klar die SSD.
 
So habe jetzt wieder den entsprechenden Rechner in den Fingern. Bei
sysctl -a | grep eli
sehe ich nichts was mit TRIM zusammenhängen könnte. Ich will halt die schöne SSD nicht frühzeitig ruinieren. Ich vertraue jetzt erstmal darauf, was Yamagi sagt, aber ich finde nichts hierzu im Internet, was ich verwerten könnte. Außerdem war ich der Meinung, daß geli die Blöcke nicht verwürfelt, also ZFS die Kontrolle über die Blöcke hat. Und da soll man es aus Gründen nicht einschalten, weil ZFS das besser kann (So habe ich es zumindest verstanden).
 
zpool iostat -r <pool> -> letzte Spalte

https://github.com/openzfs/zfs/blob...dd9d64537663c6aee3/module/zfs/vdev_trim.c#L61 -> autotrim begrapscht alles ab 32K, alles drunter müsstest du manuell machen, wenn gewünscht.

zpool status -t <pool> -> https://man.freebsd.org/cgi/man.cgi?query=zpool-trim&sektion=8&n=1

Edit:
Ergänzend dazu noch geli list ada0p$.eli und da auf das flag BIO_DELETE achten.
geli configure -t aktiviert und geli configure -T deaktiviert.

Außerdem war ich der Meinung, daß geli die Blöcke nicht verwürfelt, also ZFS die Kontrolle über die Blöcke hat. Und da soll man es aus Gründen nicht einschalten, weil ZFS das besser kann (So habe ich es zumindest verstanden).
Zum Vergrößern anklicken....

geli(8)

man.freebsd.org man.freebsd.org
Beim deaktivieren (also -T) heißt es:
-T Don't pass through BIO_DELETE calls (i.e.,
TRIM/UNMAP). This can prevent an attacker
from knowing how much space you're actually
using and which sectors contain live data, but
will also prevent the backing store (SSD, etc)
from reclaiming space you're not using, which
may degrade its performance and lifespan. The
underlying provider may or may not actually
obliterate the deleted sectors when TRIM is
enabled, so it should not be considered to add
any security.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Jetzt muß ich nochmal nachfragen. Wenn ich Yamagi richtig verstehe, ist das Trim im geli integriert und sollte deshalb im ZFS ausgeschaltet sein. Wenn ich Mr. 44er richtig verstehe, soll zpool das Trim machen (deswegen mit '-t' durchreichen. Wenn ich den im ersten Post genannten Artikel richtig verstehe sollte man bei ZFS , großer Platte mit viel freien Speicher TRIM eher deaktiviert lassen.
Damit jetzt keiner raten muß, was bei mir eingestellt ist:
$ zpool status -t pool: zroot state: ONLINE config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 nvd0p3.eli ONLINE 0 0 0 (100% trimmed, completed at Thu Feb 23 19:48:05 2023) errors: No known data errors
Den Trim am Thu Feb 23 hatte ich händisch angestoßen

zpool iostat -r <pool> -> letzte Spalte (TRIM) ==> 0 0 $ geli list Geom name: nvd0p3.eli State: ACTIVE EncryptionAlgorithm: AES-XTS KeyLength: 256 Crypto: accelerated software Version: 7 UsedKey: 0 Flags: BOOT, GELIBOOT, AUTORESIZE KeysAllocated: 233 KeysTotal: 233 Providers: 1. Name: nvd0p3.eli Mediasize: 997782974464 (929G) Sectorsize: 4096 Mode: r1w1e1 Consumers: 1. Name: nvd0p3 Mediasize: 997782978560 (929G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2421161984 Mode: r1w1e1
 
serie300 schrieb:
Wenn ich Yamagi richtig verstehe, ist das Trim im geli integriert und sollte deshalb im ZFS ausgeschaltet sein.
Zum Vergrößern anklicken....
Er meinte, dass man es ruhig im ZFS angeschaltet lassen kann und sollte und wie @Andy_m4 es sagt, dass ZFS das an geli meldet und geli das durchreicht, was das BIO_DELETE ist. Mich wundert jetzt nur, dass es default bei dir nicht aktiv ist. Kann jetzt auch sein, dass hier 'kann es' mit 'ist auch default aktiv' verwechselt wurde. Das ist jetzt das Ding, welches ich nicht weiß.

serie300 schrieb:
Wenn ich Mr. 44er richtig verstehe, soll zpool das Trim machen (deswegen mit '-t' durchreichen.
Zum Vergrößern anklicken....
Wir meinen wahrscheinlich alle das Gleiche. Es (BIO_DELETE, passthrough) muss unter geli aktiviert werden (-t), damit autotrim (und der manuelle) überhaupt funktionieren kann. Ich würde sagen, du aktivierst es mal unter geli, setzt dann autotrim auf on, schreibst und löschst mal ein paar testfiles und guckst erneut mit zpool iostat -r nach ein paar Minütchen.
serie300 schrieb:
Wenn ich den im ersten Post genannten Artikel richtig verstehe sollte man bei ZFS , großer Platte mit viel freien Speicher TRIM eher deaktiviert lassen.
Zum Vergrößern anklicken....
Eher nein. Da wird nur abgeraten, weil man bei autotrim keine Kontrolle darüber hat, wann getrimmt wird. Das kann doof sein, wenn die SSD mit der Aufgabe nicht gut umgehen kann (oft bei Billigdingern, es blockt dann I/O für einige Sekunden oder hängt sich ganz weg) und wenn man genau dann noch einen Kopiervorgang laufen hat. Sollte das bei einer aktuellen MarkenSSD auftreten, schleunigst nach einem fw-upgrade gucken...früher bei den älteren Generationen war das noch viel schlimmer.
 
Ich habe es jetzt nochmal in einer VM durchgespielt. Nicht, weil ich recht haben will, sondern weil es mich irrtierte. ;) TRIM ist standmäßig eingeschaltet, in geli list wird das nicht gelistet. Schaltet man es ab, steht es als NODELETE in den Flags.

Vielleicht zum Verständnis: ZFS unterstützt Online-TRIM, das TRIM-Kommando wird geschickt, sobald Blöcke freigegeben werden. Das ist das autotrim Property und in Standardeinstellung deaktiviert. Vor allem, da einige SSDs sich mit TRIM sehr viel Zeit lassen und solange für weitere Kommandos blockieren. Moderne, gute SSDs haben das Problem meist nicht. Außerdem wird mit zpool trim Offline-TRIM unterstützt. Es kann jederzeit ausgeführt werden und sendet für jeden nicht belegten Block ein TRIM-Kommando an die SSD. Es markiert also gegenüber den SSD-Controller als unbelegt, was auch tatsächlich unbelegt ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben