zfs scrub viel langsamer unter FreeBSD15

[h^2]

Ich habe letzte Woche gemerkt, dass die ZFS scrubs auf meinem Server deutlich langsamer geworden sind. Ich habe einen NVME RaidZ1, der unter FreeBSD14 knapp 11GB/s schrubben konnte. Dadurch war ein scrub von meinem 11TB raid in ca. 12min fertig. Genaueres Setup und Dokumentation hier). Meine Analyse war, dass das so schnell ist, weil avx2 für Prüfsummen und die Encryption benutzt wird.

Auf jeden Fall schafft er jetzt "nur noch" knapp 3GB/s, und braucht damit statt 12min ca. 50min. Dummerweise habe ich als erste Reaktion den Pool upgegradet, weil ich mir dachte "vielleicht braucht FreeBSD15 neue Features", was natürlich Quatsch ist, und jetzt kann ich auch nicht mehr auf FreeBSD14 zurück zum Debuggen.

Ist euch ein bestimmtes Problem bekannt? Wie würdet ihr das debuggen? Ich habe schon gecheckt, ob CPUs oder NVMEs stärkeres Powersave machen, aber die sichtbaren Einstellungen (sysctl dev.hwpstate_intel.*.epp für die CPUs und nvmecontrol power -p X nvmeYns1 für die Disks) haben sich nicht verändert.

 

[pit234a]

da möchte ich wirklich nicht OT werden, aber vielleicht passt meine Frage doch generell zum Thema:
Was nutzt mir denn ein Scrub überhaupt und weshalb will ich den regelmäßig machen?

Seit ich ZFS nutze (also etwa seit FreeBSD 7), habe ich vielleicht ein dutzend mal einen scrub laufen lassen (auf unterschiedlichen PCs) und dabei nie irgendeinen Nutzen festgestellt. Davon abgesehen, dass dabei mal marode HDs entdeckt wurden, weil die Belastung spontan durch den Scrub angestiegen war und sie das nicht mehr bewältigen konnten.
Daten, die korrupt auf einem ZFS liegen und die ich nicht aktiv brauche, machen mir auch keinen Kropf. Wenn ich dann merke, dass sie korrupt sind, weil ich sie nutzen möchte, ist das doch früh genug, aktiv zu werden. Ein Scrub findet solche Dinge womöglich schon im Vorfeld, vielleicht aber auch nicht.

Ein Scrub ist kein fsck und kein defrag.
Ich meine das nicht provokant, sondern, weil ich selbst lernen möchte und nicht von der man-page, sondern aus der Praxis:
Was nutzt mir ein ein Scrub überhaupt und weshalb will ich den regelmäßig machen?

 

[Azazyel]

Was nutzt mir ein ein Scrub überhaupt und weshalb will ich den regelmäßig machen?

Scrub ist wie eine Vorsorgeuntersuchung.

Zum einen möchtest du Probleme entdecken, bevor sie sich ausbreiten. Wenn du z.B. ein RAID-Z1 hast und eine Festplatte defekte Daten meldet, kannst du die Daten bequem reparieren, bevor eine zweite Festplatte Zicken macht. Ohne Scrub bemerkst du das vielleicht erst, wenn der Datenverlust schon eingetreten ist.

Zum andere möchtest du Probleme zu einer für dich genehmen Zeit finden und nicht erst in einem Augenblick, in dem du dringend auf den Zugriff auf die Daten angewiesen bist.

 

[medV2]

da möchte ich wirklich nicht OT werden, aber vielleicht passt meine Frage doch generell zum Thema:
Was nutzt mir denn ein Scrub überhaupt und weshalb will ich den regelmäßig machen?

Ich mache ca. 2x im Jahr ein Scrub über alle meine Pools.

Seit ich ZFS nutze (also etwa seit FreeBSD 7), habe ich vielleicht ein dutzend mal einen scrub laufen lassen (auf unterschiedlichen PCs) und dabei nie irgendeinen Nutzen festgestellt. Davon abgesehen, dass dabei mal marode HDs entdeckt wurden, weil die Belastung spontan durch den Scrub angestiegen war und sie das nicht mehr bewältigen konnten.
Daten, die korrupt auf einem ZFS liegen und die ich nicht aktiv brauche, machen mir auch keinen Kropf. Wenn ich dann merke, dass sie korrupt sind, weil ich sie nutzen möchte, ist das doch früh genug, aktiv zu werden. Ein Scrub findet solche Dinge womöglich schon im Vorfeld, vielleicht aber auch nicht.

Ein Scrub ist kein fsck und kein defrag.
Ich meine das nicht provokant, sondern, weil ich selbst lernen möchte und nicht von der man-page, sondern aus der Praxis:
Was nutzt mir ein ein Scrub überhaupt und weshalb will ich den regelmäßig machen?

@Azazyel Hat eigentlich schon alles erklärt, man will Fehler frühzeitig und zu genehmen Zeiten erkennen.



Zum eigentlichen Thema hab ich leider nichts beizutragen, ich betreibe kein ZFS auf NVME und auf normalen Platten oder auch SATA SSDs ist nichts merkbar.

 

[mr44er]

Was nutzt mir ein ein Scrub überhaupt und weshalb will ich den regelmäßig machen?

Der meldet sofort, ob Daten von bit rot https://www.computerweekly.com/de/definition/Bit-Rot betroffen sind oder nicht. Das heißt nicht zwangsläufig, dass damit die Platte auch defekt ist. Kommt viel häufiger vor, als man denken mag.
Die Daumenregel sagt: Consumerplatten alle drei Monate scrubben, Enterpriseplatten (die haben zwar patrol read, aber keine eigene Redundanz zur Reparatur, daher nur nice to have) alle sechs Monate scrubben. Je nachdem wie wichtig einem die Daten sind, kann man die goldene Mitte nehmen.
Wöchentlich scrubben ist nur für Paranoide notwendig, diese Belastung killt aber die Platten ziemlich sicher vorschnell.

Ist euch ein bestimmtes Problem bekannt? Wie würdet ihr das debuggen?

Nichts bekannt, aber wenn gstat überall auf rot/100 steht, geht da nicht mehr.

 

[turrican]

Auf jeden Fall schafft er jetzt "nur noch" knapp 3GB/s, und braucht damit statt 12min ca. 50min.

sind evtl. CAP und FRAG Werte hoch bei deinem Pool?
volllaufen - das verlangsamt den gesamten Pool (zumindest bei meinen), auch die Scrubs - bei einem hab ich 92% CAP und 63% FRAG

Was nutzt mir denn ein Scrub überhaupt und weshalb will ich den regelmäßig machen?

du läßt nen Pool mit vfs.zfs.recover="1" laufen, da kommts auf nen scrub auch nimmer an (sorry, kein Angriff auf dich, konnte nicht widerstehen)

 

[turrican]

Wöchentlich scrubben ist nur für Paranoide notwendig, diese Belastung killt aber die Platten ziemlich sicher vorschnell.

kann ich aus meiner Warte nicht bestätigen - weder auf rotierendem Rost noch auf Chip-Basis;
hatte jahrelang wöchtenlich (Sonntag Nacht) nen scrub auf den pools - keine erhöhten Defekte merkbar, ich hatte mehr DOA - wobei meine paar Platten da ggf nicht aussagekräftig genug sind, da müsste man evtl. mal in nem Datencenter nachschauen, so ab 500 - 800 Platten wirds wohl interessant (aussagekräftiger)

 

[mr44er]

Also ich sage mal bei nem mirror von zwei vdevs/platten läuft der scrub schneller durch und somit ist das keine tagelange Last. Ich bin hier mit 24 Platten bei 48-50h angelangt, die ein scrub braucht.
Und natürlich wie vollgestopft mit Linux-isos/Pornos/Urlaubsbildern das ist.

 

[pit234a]

du läßt nen Pool mit vfs.zfs.recover="1" laufen, da kommts auf nen scrub auch nimmer an (sorry, kein Angriff auf dich, konnte nicht widerstehen)

absolut froh, für solche Hinweise.
Kurz gesagt (als Laie), nutze ich meist ZFS so, wie es kommt und lese nicht mit jeder Version die man-page und was man nun neu ändern kann. Ob ich vfs.zfs.recover="1" gesetzt habe und was das macht, weiß ich nicht, will nun aber auch grad nicht nachsehen.

Mal anders gesagt:
wenn mir scrub defekte oder geschrottete Daten findet, brauche ich doch meinen Backup und den muss ich ja schon vorher gemacht haben.
Hier sehe ich natürlich das Problem, dass ich ohne vorherigen Scrub eigentlich kein Backup machen sollte, weil ich sonst womöglich defekte Datenpakete mit sichere.
Wenn das aber so ist, dann sollte wohl hier irgendein ein Automatismus bestehen?
Soll ich also vor jedem Backup erst die Quell- und Ziel-Pools scrubben?
Das macht doch jeden Backup zu einem Langzeit-Projekt.

 

[Azazyel]

kann ich aus meiner Warte nicht bestätigen - weder auf rotierendem Rost noch auf Chip-Basis; hatte jahrelang wöchtenlich (Sonntag Nacht) nen scrub auf den pools - keine erhöhten Defekte merkbar, ich hatte mehr DOA - wobei meine paar Platten da ggf nicht aussagekräftig genug sind, da müsste man evtl. mal in nem Datencenter nachschauen, so ab 500 - 800 Platten wirds wohl interessant (aussagekräftiger)

Es steht zwar nicht in der aktuellen Backblaze-Statistik, aber die drei Todsünden sind:

• Hitze/Temperaturschwankungen
• Vibrationen
• starke Erschütterungen bei laufender Festplatte

Dauerbetrieb (nicht nur idle, sondern auch Schreib-Lese-Zugriffe) können moderne HDDs verdammt gut ab.

Hier sehe ich natürlich das Problem, dass ich ohne vorherigen Scrub eigentlich kein Backup machen sollte, weil ich sonst womöglich defekte Datenpakete mit sichere.
Wenn das aber so ist, dann sollte wohl hier irgendein ein Automatismus bestehen?
Soll ich also vor jedem Backup erst die Quell- und Ziel-Pools scrubben?
Das macht doch jeden Backup zu einem Langzeit-Projekt.

Solltest ZFS beim Backup einen Fehler finden, wir es ihn entweder korrigieren (falls ausreichend Redundanz vorhanden ist) oder einen Fehler beim Lesen werfen, womit das Backup abbricht (und deine Backup-Software kann hoffentlich damit umgehen).

Man sollte zumindest monatlich Scrub laufen lassen, gerne auch häufiger.

Mir persönlich ist die Gewissheit, dass ich gegenüber dem häufigsten Fehlerszenario (genau eine Festplatte fällt aus) gut gewappnet bin, den vernachlässigbaren Mehrverbrauch an Energie und geringfügig mehr Verschleiß allemal wert.

 

[pit234a]

Motiviert, durch die Beiträge zuvor, habe ich nun mal einige Scrubs angeworfen und komme niemals auf Werte, die auch nur in der Nähe von

knapp 11GB/s schrubben

Mein Mirror auf NVMEs auf meinem FreeBSD 14 (System-Pool, also nicht nur Daten), kommt vielleicht auf 1,5GB/s, alle anderen sind deutlich langsamer.
Mein Uralt raidz2 aus 6 x 4TB HDs auf einem Uralt FreeBSD (7.4-RELEASE-p9), meint, noch etwa zehn Tage zu brauchen, oder etwas mehr.
Mein dieser Tage erst auf FreeBSD15 upgedateter Think-Pad mit zwei SSDs im mirror (system) kommt auf etwa 370M/s.

Daraus folgere ich mal, dass mehr Faktoren für die Geschwindigkeit eines Scrub relevant sind, als wir bisher hier gelesen haben und insofern der Vergleich zwischen FreeBSD 14 und FreeBSD 15 sicher nicht ganz einfach sein wird.

 

[medV2]

wenn mir scrub defekte oder geschrottete Daten findet, brauche ich doch meinen Backup und den muss ich ja schon vorher gemacht haben.
Hier sehe ich natürlich das Problem, dass ich ohne vorherigen Scrub eigentlich kein Backup machen sollte, weil ich sonst womöglich defekte Datenpakete mit sichere.
Wenn das aber so ist, dann sollte wohl hier irgendein ein Automatismus bestehen?
Soll ich also vor jedem Backup erst die Quell- und Ziel-Pools scrubben?
Das macht doch jeden Backup zu einem Langzeit-Projekt.

Das beim Backup ja festgestellt wird, ob die Datenfehlerhaft sind, wurde schon geschrieben. Was aber auch wichtig ist: Im Idealfall, oder eigentlich im Regelfall, hat man ein Backup was versioniert, also Daten nicht überschreibt. Wenn du also Urlaubsvideo.mkv im Jannuar backupst, im März wird eine fehlerhafte Kopier darüber geschrieben, sollte dein Backup immer noch deine Jannuarversion ausgeben können. Halbwegs kompakte Tools die sowas machen wären zB restic, borg oder zpaq für nen etwas anderen Ansatz. Und natürlich die full-blown Lösungen wie Bacula/Bareos.

Motiviert, durch die Beiträge zuvor, habe ich nun mal einige Scrubs angeworfen und komme niemals auf Werte, die auch nur in der Nähe von

Mein Mirror auf NVMEs auf meinem FreeBSD 14 (System-Pool, also nicht nur Daten), kommt vielleicht auf 1,5GB/s, alle anderen sind deutlich langsamer.
Mein Uralt raidz2 aus 6 x 4TB HDs auf einem Uralt FreeBSD (7.4-RELEASE-p9), meint, noch etwa zehn Tage zu brauchen, oder etwas mehr.
Mein dieser Tage erst auf FreeBSD15 upgedateter Think-Pad mit zwei SSDs im mirror (system) kommt auf etwa 370M/s.

Daraus folgere ich mal, dass mehr Faktoren für die Geschwindigkeit eines Scrub relevant sind, als wir bisher hier gelesen haben und insofern der Vergleich zwischen FreeBSD 14 und FreeBSD 15 sicher nicht ganz einfach sein wird.

NVME ist nicht gleich NVME. Zum einen gibt es NVME Platten, die eigentlich intern SATA sind (sind dann meist die günstigen), und es gibt natürlich von PCI-Express 2-5 alle möglichen Geschwindigkeiten. Die langsamste in meinem Gamingrechner liest irgendwo 3 GB/s, die schnellste 10 GB/s

 

[Azazyel]

Das beim Backup ja festgestellt wird, ob die Datenfehlerhaft sind, wurde schon geschrieben. Was aber auch wichtig ist: Im Idealfall, oder eigentlich im Regelfall, hat man ein Backup was versioniert, also Daten nicht überschreibt. Wenn du also Urlaubsvideo.mkv im Jannuar backupst, im März wird eine fehlerhafte Kopier darüber geschrieben, sollte dein Backup immer noch deine Januarversion ausgeben können.

Ganz wichtig - ich habe schon genug Unixler weinen sehen, weil ihr selbstgebasteltes Backup mit rsync o.ä. die korrekte Version im Backup mit einer defekten Version überschrieben hat.

Halbwegs kompakte Tools die sowas machen wären zB restic, borg oder zpaq für nen etwas anderen Ansatz. Und natürlich die full-blown Lösungen wie Bacula/Bareos.

Das ist eine gute Liste an Empfehlungen mit meinem persönlichen Favoriten restic.

 

[turrican]

Ein scrub ist vorwiegend ein "read-only" Lastfall für die Platte - d.h. wenn DAS deine Platte schon schädigt, dann wär sie sowieso demnächst ausgefallen;

was anderes ist ein resilver - das beansprucht die Mechaniken nochmal ganz anders, kann man bei rotierendem Rost und nem RaidZ(2,3) auch ganz gut akustisch hören

früher war im periodic das scrubbing auf alle 35 Tage gesetzt was für den normalen Anwendungsfall eigentlich doch auch reicht;
Sonntag Nacht zwischen 1 und 3 wars glaub ich


@pit234a: quasi vor genau 3 Jahren

Thema 'vfs.zfs.recover="1" in loader.conf: entstehen dadurch Nachteile?'

16 April 2023

vfs.zfs.recover="1" in der /boot/loader.conf hat mir eben sehr geholfen.

Vorausgegangen ist ein unerklärlicher Crash einiger zpools, darunter auch mein ROOT-pool.

Wie das passiert ist, weiß ich gar nicht.
Wann das passierte schon etwas besser. Nämlich, nachdem ich, wie inzwischen ja gewohnt eher nebenbei einen freebsd-update von 13.1 auf 13.2 gemacht hatte. Die meisten Fehler passieren mir dabei dann, wenn ich nochmal beim Mergen Hand anlegen will, weil ich da unbedingt noch was verbessern möchte. An sowas habe ich mich also bereits gewöhnt und mache niemals einen Upgrade ohne einen...

• pit234a
• Antworten: 66
• Forum: FreeBSD - Installation

 

[pooltechniker]

Wöchentlich scrubben ist nur für Paranoide notwendig, diese Belastung killt aber die Platten ziemlich sicher vorschnell.

Unter Solaris 11.4 läuft per Default für jeden Pool ein wöchentlicher Scrub. Ich hab bei einer dreistelligen Anzahl an Servern noch keinen erhöhten Verschleiß an Disks oder NVMe's bemerkt, Defekte sind hier extrem selten.

 

[turrican]

Ist euch ein bestimmtes Problem bekannt? Wie würdet ihr das debuggen?

wie gesagt: ein scrub ist ein read-only Vorgang - d.h. du hast im Prinzip ein "Lese"-Durchsatz-Problem auf deinem Pool

gibt es bereits I/O parallel auf dem pool? ein scrub kann parallel dazu laufen, die Performance bei beiden leidet natürlich dann darunter;

hast du mal ins Log geschaut, ob ggf CAM Einträge vorhanden sind? (könnte auf H/W Problem hinweisen);

EDIT: weitere Vorschläge hinzugefügt:

Nen zpool iostat ... mal dazu laufen lassen?

SMART Werte der zugehörigen Platten (nvmes) mal ausgelesen und auf Veränderung geprüft?

Wie weiter oben schon gesagt: pool läuft voll? CAP >80%, FRAG hoch? (zpool list -v)

prefetch mal testweise ausschalten: vfs.zfs.prefetch.disable=1

auch in Kombination / bzw standalone mit scrub prefetch: vfs.zfs.no_scrub_prefetch=1

 

[pit234a]

quasi vor genau 3 Jahren

ah ja. also zu vfs.zfs.recover="1"
Das war aber ein Notfall-Szenario.
Inzwischen ist die HW komplett neu und der Pool erfolgreich umgezogen. Was allerdings gar nicht sooo einfach war, oder, was ich mir selbst gar nicht so einfach gemacht hatte, weil ich einen Pool auf neuer HW erstellt hatte, mit neuen Eigenschaften und Data-Sets und dann diese erst mit Inhalten aus dem alten Pool füllte.
Es ging dabei auch um den System-Pool, also kein "Daten-Grab" und deshalb wollte ich den zarten Umstieg und die Lebensverlängerung durch Notbeatmung des alten Pools.

 

[h^2]

Hallo Leute, ich würde gerne mal wieder zum Topic zurück

gstat zeigt Folgendes:

 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    2   2689   2689 834825    1.1      0      0  0.000   99.8| nda0
    0   2795   2795 833970  0.272      0      0  0.000   51.4| nda1
    2   2806   2806 833510  0.228      0      0  0.000   45.2| nda2
    0   2810   2810 834050  0.209      0      0  0.000   42.7| nda3

Was ziemlich interessant aussieht. nda0 ist eigentlich immer am Anschlag, die anderen sind meistens um die 35-50% busy und springen selten mal kurz auf 60 oder so. Und das, obwohl die Anzahl der reads und die OPS gleich sind. Was ist ms/r? Das ist ja 4x höher als bei den anderen.

Ich ärgere mich wirklich, dass ich den aktualisiert habe und nicht mit einem 14er FreeBSD booten kann und vergleichen.

 

[mr44er]

Was ist ms/r?

Die latency für reads.

Ich ärgere mich wirklich, dass ich den aktualisiert habe und nicht mit einem 14er FreeBSD booten kann und vergleichen.

Musst du nicht und ist auch nicht dein Problemverursacher.

Das Problem ist ja schon gefunden, mit nda0 ist irgendwas und das bremst alles aus.

Zeig' mal, was smartctl -x /dev/ndaX meint.

Edit:
Und bitte noch auch jeweils von den namespaces.

 

[h^2]

Das Problem ist ja schon gefunden, mit nda0 ist irgendwas und das bremst alles aus.

Hm, bei den aktuellen Preisen hoffe ich nicht, dass ich ersetzen muss

Zeig' mal, was smartctl -x /dev/ndaX meint.

Auf den nda* kann ich kein smartctl aufrufen, wohl aber auf /dev/nvmeX. Die habe ich angehangen.

Und bitte noch auch jeweils von den namespaces.

Die Smartctl logs? Habe ich angehangen, unterscheiden sich aber nicht von den regulären Logs (bis auf ein paar bytes mehr gelesen/geschrieben).

 

[mr44er]

Hm, bei den aktuellen Preisen hoffe ich nicht, dass ich ersetzen muss

Psssst, Vorratshaltung! Mindestens einmal sollte man alle im Einsatz befindlichen Speichergeräte nochmals im Schrank liegen haben. Aber ja, jetzt kaufen wäre tödlich.

Auf den nda* kann ich kein smartctl aufrufen, wohl aber auf /dev/nvmeX. Die habe ich angehangen.

Upsie, ja korrekt.

Die Smartctl logs? Habe ich angehangen, unterscheiden sich aber nicht von den regulären Logs (bis auf ein paar bytes mehr gelesen/geschrieben).

Ja, auch korrekt. Je nach Typ zeigt das noch anderes an, hier ists aber tatsächlich gleich mit der Ausgabe, macht nix.

Dummerweise ist da nichts zu sehen. Lediglich die mit der SN NHA487R001067P2202 hat Warning Comp. Temperature Time: 7, das dürfte aber noch nicht drosseln, weil es nur 7x war und keine "criticals".
Ist das der Kandidat? Mir fiel doch noch was auf...das ist eine andere Charge mit ggf. minderwertigeren Bauteilen. Alle anderen drei fangen bei der SN mit NJF an.

 

[h^2]

Ist das der Kandidat?

Ne, das Problemkind ist nda0 , also nvme0 (oder findet da ein anderes remapping statt!?).

Den, den du identifiziert hast, ist nvme3, also nda3.

 

[mr44er]

Ne, das Problemkind ist nda0 , also nvme0 (oder findet da ein anderes remapping statt!?).

Da bin ich mir gerade nicht sicher.

camcontrol devlist
nvmecontrol devlist
nvmecontrol identify nvme0

etc. sollte das bestätigen. Nur um absolut sicher zu gehen.

Da bin ich jetzt aktuell überfragt.
Rein auf Verdacht würde ich das Gehäuse öffnen und einen starken Ventilator draufpusten lassen und dann erneut beim scrub gucken, ob dann alle bei gstat 100% peaken.
Rein auf Verdacht2 würde ich die Firmware bei allen updaten, denn irgendeinen Grund muss es geben, dass es eine neuere gibt. https://smarthdd.com/database/Lexar-SSD-NM790-4TB/16949/

Vermutlich wird die Prozedur aber eklig, weil du da nur mit Win-Software rankommst: https://www-oss.lexar.com/lexar/resource/files/2025-08-27/Lexar DiskMaster1.1.8(EN).zip

 

[Yamagi]

Es könnte sich auch lohnen nochmal nach Partitionsalignement zu schauen. Wobei dort die Frage wäre, wieso es erst jetzt zum Problem geworden ist.

 

[h^2]

Da bin ich mir gerade nicht sicher.

camcontrol devlist nvmecontrol devlist nvmecontrol identify nvme0 etc. sollte das bestätigen. Nur um absolut sicher zu gehen

# camcontrol devlist
<Lexar SSD NM790 4TB 12237>        at scbus0 target 0 lun 1 (pass0,nda0)
<Lexar SSD NM790 4TB 12237>        at scbus1 target 0 lun 1 (pass1,nda1)
<Lexar SSD NM790 4TB 12237>        at scbus2 target 0 lun 1 (pass2,nda2)
<Lexar SSD NM790 4TB 12237>        at scbus3 target 0 lun 1 (pass3,nda3)
# nvmecontrol devlist
 nvme0: Lexar SSD NM790 4TB
    nvme0ns1 (3907018MB)
 nvme1: Lexar SSD NM790 4TB
    nvme1ns1 (3907018MB)
 nvme2: Lexar SSD NM790 4TB
    nvme2ns1 (3907018MB)
 nvme3: Lexar SSD NM790 4TB
    nvme3ns1 (3907018MB)

Kann ich dadurch wirklich darauf schließen, dass nda0 <=> nvme0 ? identify hilft da auch nicht weiter...

Rein auf Verdacht2 würde ich die Firmware bei allen updaten, denn irgendeinen Grund muss es geben, dass es eine neuere gibt

Ja, das könnte ich mal machen.

Vermutlich wird die Prozedur aber eklig, weil du da nur mit Win-Software rankommst

Es gibt doch nvmecontrol firmware, oder sollte man da besser die Finger von lassen?

Es könnte sich auch lohnen nochmal nach Partitionsalignement zu schauen. Wobei dort die Frage wäre, wieso es erst jetzt zum Problem geworden ist.

Die haben haargenau dasselbe Alignment:

# gpart show
=>        40  8001573472  nda0  GPT  (3.7T)
          40     2097152     1  efi  (1.0G)
     2097192        2008        - free -  (1.0M)
     2099200    16777216     2  freebsd-swap  (8.0G)
    18876416   205520896     3  freebsd-ufs  (98G)
   224397312  7777175552     4  freebsd-zfs  (3.6T)
  8001572864         648        - free -  (324K)

=>        40  8001573472  nda1  GPT  (3.7T)
          40     2097152     1  efi  (1.0G)
     2097192        2008        - free -  (1.0M)
     2099200    16777216     2  freebsd-swap  (8.0G)
    18876416   205520896     3  freebsd-ufs  (98G)
   224397312  7777175552     4  freebsd-zfs  (3.6T)
  8001572864         648        - free -  (324K)

=>        40  8001573472  nda2  GPT  (3.7T)
          40     2097152     1  efi  (1.0G)
     2097192        2008        - free -  (1.0M)
     2099200    16777216     2  freebsd-swap  (8.0G)
    18876416   205520896     3  freebsd-ufs  (98G)
   224397312  7777175552     4  freebsd-zfs  (3.6T)
  8001572864         648        - free -  (324K)

=>        40  8001573472  nda3  GPT  (3.7T)
          40     2097152     1  efi  (1.0G)
     2097192        2008        - free -  (1.0M)
     2099200    16777216     2  freebsd-swap  (8.0G)
    18876416   205520896     3  freebsd-ufs  (98G)
   224397312  7777175552     4  freebsd-zfs  (3.6T)
  8001572864         648        - free -  (324K)

Was mir dafür noch eingefallen ist:
Ein einziger der NVME-slots des Mainboards ist PCIe-5.0 und der geht über die CPU. Die anderen sind PCIe-4.0 und gehen über den Chipsatz. Vielleicht hat sich da bei FreeBSD15 etwas geändert? Oder die CPU firmware..?