Au Backe, das wird jetzt etwas länger...
Das initiale Problem war, dass zusätzliche Geräte mit "zfs attach" zum bestehenden vdev hinzugefügt werden. "zfs add" erstellt ein neues vdev. Das geht aber bei raidZ nicht (ohne weiteres) - ein Pool mit raidZ-vdevs wird normalerweise immer um weitere vdevs identischer größe/konfiguration erweitert, nie durch einzelne Platten.
Das vorhandene (und einzige) vdev ist ausserdem _viel_ zu groß - die Performance des vdevs und damit des pools ist vermutlich (sicher) unterirdisch.
Ganz grobe Faustregel für raidZ: Wurzel aus gesamter Plattenzahl (ggf der geplanten Vollbestückung) + raidZ-Level entspricht der maximalen Anzahl Geräte je vdev. Ist man da drüber macht man definitiv was falsch (oder man weiß _SEHR_ genau warum man es doch anders macht!).
Bsp: bei 48 Platten in Vollbestückung mit raidZ3 sollten die vdevs im extremfall MAXIMAL aus 10 Geräten bestehen (wurzel aus 48 = 6.9 + raidZ3 = 9.9).
Je mehr Platten je vdev, desto mehr IOPS und Bandbreite büßt der gesamte Pool ein. Anders herum: je mehr VDEVs, desto mehr Geräte werden parallel genutzt und desto höher der gesamtdurchsatz des pools. Dein Pool hat maximal den Durchsatz der langsamsten einzelnen Platte (sprich: katastrophal schlecht).
Ein Pool aus raidZ3-vdevs sollte auch immer nur mit weiteren raidz3-vdevs gleicher größe erweitert werden. In deinem Fall also 29 (!!!) Geräte. Spätestens hier sollte schon klar sein, dass da was ganz gewaltig verbockt wurde...
Da raidZ relativ unflexibel ist, sollte man sich sehr gut überlegen, ob man nicht evtl mit mirror-vdevs besser fährt. Hier ist eine erweiterung immer um einen neuen mirror möglich, wobei ein mirror auch aus mehr als 2 Geräten bestehen kann, falls höhere Redundanz erforderlich ist. Weiterer vorteil von mirror-vdevs: der Pool hat eine deutlich höhere IOPS-Leistung und mit "zfs split" lässt sich ein klon des pools abspalten, z.b. für ein initiales fullbackup an einem offsite-system.
Meine dringende Empfehlung: Da die beiden hinzugefügten Platten aktuell ohne jegliche redundanz verwendet werden, füge zumindest jeweils noch ein device identischer größe hinzu (evtl von den spares abzwacken?) um zumindest nen mirror draus zu machen.
Sinnvollster Ausweg wäre dann eine Sicherund der datasets aus diesem Pool per zfs send/receive in einem anderen pool / dateien auf nem Fileserver / Bändern / S3 oder anderem cloud-storage etc pp... Dann lege den Pool neu an mit mehreren kleineren vdevs. Dieser Pool ist praktisch nicht (sinnvoll) erweiterbar, da dieses riesen-vdev die Performance immer in den Keller ziehen wird.
Mit inkrementellen send/receive lässt sich das backup nach und nach mit immer kürzeren abständen synchronisieren, sodass die downtime minimal gehalten werden kann. Bzw wenn ein zweiter pool (hot-backup) zur Verfügung steht, wäre theoretisch sogar eine migration ohne downtime möglich (je nach nutzung des Pools natürlich - bei VMs mit datenbanken würde ichs nicht riskieren).
Zwei weitere Ratschläge:
- binde Laufwerke unbedingt mit aussagekräftigen Bezeichnungen ein. Die letzten 5-7 Stellen der Seriennr und/oder die physische Position (z.b. controller/enclosure/backplane oder gehäuse/reihe/position) als GPT-Label oder zumindest die WWN sind gute Varianten und lassen sich sowohl per Software als auch direkt auf der Platte bzw am shelf/backplane/jbod einfach ermitteln. Zusätzlich gehören natürlich die caddies entsprechend beschriftet. Mit "sdt" kann keine Sau etwas anfangen wenn mitten im Urlaub eine Platte abraucht und man per Telefon jemanden der keine Ahnung von dem System hat erklären muss, welche Platte er ersetzen soll... Zumal die sdX-Bezeichnungen völlig willkürlich vergeben werden - werden Platten ersetzt oder hinzugefügt, stimmen die Bezeichnungen beim nächsten reboot nicht mehr und der pool kann nicht importiert werden.
- Bei so großen Pools sind cache- und log-devices eigentlich unverzichtbar um die Performance auch bei Spitzenlasten gleichmäßig zu halten. Bei der Poolgröße kommen praktisch nur noch NVMe bzw PCIe-SSDs in Betracht - allein schon um die HBAs nicht zusätzlich zu belasten und auch um den nötigen I/O bereit zu stellen. SSDs an SAS/SATA haben nur einen queue mit max 64 einträgen, da sie sich wie "dumme" HDDs verhalten müssen (Stichwort FTL) - NVMe/PCIe haben bis zu 64k queues mit 64k Tiefe; da wird I/O praktisch nur noch durch CPU und die Busbreite (x4, x8, x16) bzw PCIe 2 vs 2.1 vs 3 begrenzt.
Wenn du so große Pools administrierst rate dir _dringend_ dich durch Fachliteratur mit ZFS vertraut zu machen. Ich unterstelle anhand der Gröse mal, dass es sich hier nicht mehr um ein Hobby sondern ein (wichtiges) Produktivsystem handelt - wenn dir das um die Ohren fliegt wirds richtig ungemütlich... (und das wird es in der jetzigen Konfiguration - zumindest bei der Performance bereits jetzt und kapital spätestens wenn eine der beiden neuen Platten eingeht)
Die beiden Bücher von Michael W. Lucas und Alan Jude,
FreeBSD Mastery: ZFS und
Advanced ZFS, kann ich wärmstens empfehlen. Es werden nur wenige BSD-Spezifische Themen behandelt, >80% beziehen sich auf OpenZFS allgemein und sind somit Plattformübergreifend gültig, also auch für illumos oder linux. (Bei den restlichen ca 20% sieht man oft, wie angenehm logisch und einfach vieles gelöst werden kann, was unter Linux z.T. ein ziemlicher Krampf ist
)
Ach und PS: df und du sind mit ZFS die völlig falschen tools. Da ZFS (ohne quotas) den gesamten pool für alle datasets verfügbar macht, liefern df und du völlig verkehrte werte. Alles was man wissen möchte, liefert "zfs list" mit entsprechenden optionen. Die manpage ist hier der erste Anlaufpunkt - dank Solaris/Illumos-Abstammung ist diese nämlich auch umfassend und mit haufenweise Beispielen versehen