FreeBSD 13 mit OpenZFS: Empfehlungen für neue Einstellungen?

pit234a

Well-Known Member
Hintergrund meiner Frage ist, dass ich demnächst irgendwann mal meine vorhandenen SSDs ersetzen möchte und diese haben zpools, die schon mit älteren Versionen in FreeBSD angelegt wurden und nun ist ja eine weitere Kompressionsart möglich, es gibt Neuerungen zu Trimm und einige mehr. Also, beinahe schon zu viele für mich, um noch den Überblick zu behalten.
Deshalb frage ich mal in die Runde.
Wenn ich einen neuen Pool mit FreeBSD 13 auf SSD erstelle, worauf sollte ich achten, was kann ich besser machen oder was sollte ich vermeiden?
 

Andy_m4

Well-Known Member
Ich mach mal den Anfang mit ein paar Sachen die mir noch im Gedächtnis sind:

Wenn ich einen neuen Pool mit FreeBSD 13 auf SSD erstelle, worauf sollte ich achten, was kann ich besser machen oder was sollte ich vermeiden?
Den ARC nicht mehr künstlich begrenzen:
https://www.bsdforen.de/threads/kommendes-update-auf-freebsd-13.36029/page-2#post-324501

Die vfs.zfs.min_auto_ashift Geschichte:
https://www.bsdforen.de/threads/freebsd-13-0-erschienen.36110/#post-324817

Vielleicht kann man das sogar in nen generellen Hinweis umwandeln:
Wenn es keinen expliziten Grund dafür gibt, sollte man die Defaults so lassen wie sie sind.

, es gibt Neuerungen zu Trimm und einige mehr
Ein explizites zpool trim wirst Du selten brauchen.
Es gibt aber die zpool-Eigenschaft autotrim (zpool get autotrim) die Du ein und ausknipsen kannst.

zpool-trim(8)
zpoolprops(8)
 

mr44er

moderater Moderator
Teammitglied
Booting off of zstd-compressed root pools is not yet supported.
Ganz unten: https://www.freebsd.org/cgi/man.cgi?zpool-features

compression=zstd würde ich daher noch nicht (gilt das noch?) auf dem root pool setzen, ansonsten aber überall gerne. Höhere Level kannst du mit zstd-1 bis zstd-19 setzen, wobei man damit sehr vorsichtig sein sollte.

recordsize=1M kannst du bedenkenlos setzen, es unterstützt die Effizienz von lz4 und zstd und somit auch unterm Strich den Durchsatz.

zpool status -t zeigt Info zu trim.

Vorsichtig wäre ich bei SSDs, die quirky sind:
Code:
dmesg | grep quirk
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
 

stadtkind

Well-Known Member
recordsize=1M kannst du bedenkenlos setzen, es unterstützt die Effizienz von lz4 und zstd und somit auch unterm Strich den Durchsatz.
das wollte ich auch mal setzen, aber nachdem ich zfsprops(8) gelesen habe:

recordsize=size
Specifies a suggested block size for files in the file system. This
property is designed solely for use with database workloads that access
files in fixed-size records. ZFS automatically tunes block sizes
according to internal algorithms optimized for typical access patterns.
 

medV2

Well-Known Member
das wollte ich auch mal setzen, aber nachdem ich zfsprops(8) gelesen habe:

recordsize=size
Specifies a suggested block size for files in the file system. This
property is designed solely for use with database workloads that access
files in fixed-size records. ZFS automatically tunes block sizes
according to internal algorithms optimized for typical access patterns.

Ich denke das ist noch von früher, als die default recordsize auch die max recordsize war (128k). Mitlerweile gibts eben ein höheres max und das kann man idr auch setzen (gibt natürlich immer spezielle Anwendungsfälle die dagegen sprechen).
 

pit234a

Well-Known Member
Es gibt aber die zpool-Eigenschaft autotrim (zpool get autotrim) die Du ein und ausknipsen kannst.
was ja interessant ist, weil das per pool geschieht und nicht per device oder partition.
dazu habe ich insgesamt noch wenig gelesen. Vergleiche werden dann fast immer zu bzip oder so gemacht und nicht zu lz4.
In dem ein oder anderen Test, den ich dann gelesen habe, schneidet es gegenüber lz4 allerdings eher bescheiden ab, oder sagen wir mal, zumindest nicht herausragend. In keinem Fall in einer Art auffällig, dass ich von mir aus nun sagen würde, das muss ich heute schon haben. lz4 finde ich echt klasse und würde das eher behalten wollen, stand heute.
 

mr44er

moderater Moderator
Teammitglied
schneidet es gegenüber lz4 allerdings eher bescheiden ab

Man muss die Geschwindigkeit in Relation zur Effizienz sehen und was man eben bevorzugt. :)

Ich denke das ist noch von früher, als die default recordsize auch die max recordsize war (128k)
So ist es. Spezialfälle wären allerdings, wenn man viele (überwiegend bis ausschließlich) kleine Dateien hat und dafür extra ein Dataset erstellt. Dann lohnt es sich die recordsize entsprechend anzupassen.
 
Oben