[Sammelthread] ZFS Stammtisch

[AliManali]

Hi

Danke.

Zugriff auf napp-it würde ich gerne begrenzen, ja. Das müsste ich wohl in den Firewall Settings machen? Ich hatte schon mal ein Post dazu gemacht, aber keine Antwort bekommen. Keine Ahnung, wie das geht. Das ich da ein eigenes VLAN gemacht hatte war vor allem deshalb, weil man für NFS 3 wohl kein Passwort vergeben kann. Das wäre schon schön, wenn per NFS nur der ESXi Host zugreifen könnte.

Das geht im übrigen nicht um Plex, sondern Plesk (ein Hosting Panel). Plesk kann man leider nur lokal oder per sftp sichern. Andere Möglichkeit wäre noch, dass ich die Backup vmdk direkt an die Plesk VM hänge. Soweit hatte ich noch gar nicht überlegt. Dann müsste ich netzwerktechnisch auch nichts beregeln.

 

[gea]

Zugriff auf napp-it kann man für Management und/oder Replikation in System > Settings einschränken.
Gibt man da z.B. 192.168. ein, geht Zugriff nur aus den entsprechenden privaten Netzen.

Kann man nur lokal sichern, wäre eine vdisk oder iSCSI target (erscheint wie eine lokale Platte) viel schneller als sftp.

 

[kandamir]

Wenn man eine transparente VPN Verbindung hat (beide Seiten im gleichen LAN Segment), ist es natürlich besonders einfach. Hat man eine NAT Verbindung (mit Routing und Adresstranslation) so erreicht der Backupserver z.B. den Quellserver zwar unter dessen echter lokaler IP, eine Rückantwort kommt allerdings unter der IP des VPN/NAT Routers an. In dem Fall muss man im Backupserver in System > Einstellungen unter Swap remote_addr (ip=newip) die echte ip Adresse des Quellservers z.B. 192.168.10.11 durch die Router/NAT Adresse newip ersetzen, z.B. 192.168.10.11=192.168.1.1

Diese Option ist neu in 23.dev

Danke, @gea! Über das VPN sind zwei Subnetze gekoppelt, in jedem steht eine Napp-It Instanz. Die sehen sich aber problemlos. So habe ich beide Instanzen zu einer Appliance zusammen gefügt. Ich hatte bislang nicht den Eindruck, dass da noch was konfiguriert werden müsste, damit sich beide Seiten „unterhalten“ können, behalte das mit dem swap remote_addr aber im Hinterkopf.

Ein identischer Basisnap z.B. repli_snap_nr_821 auf beiden Seiten wird immer benötigt. Der -I Parameter sorgt lediglich dafür dass Snaps die auf dem Quellserver nach dem Snap 821 angelegt wurden mit übertragen werden und auf dem Backupserver einzeln verfügbar sind.

Bzgl. des Basis-Snaps muss ich noch einmal nachfragen. Wird da eine bestimmte Nomenklatur vorausgesetzt, wie die Snaps bezeichnet sein müssen? Oder müssen die einfach gleich heißen? Einen Zeitstempel habe ich in den Snaps i.d.R. schon, aber Deinem Beipsielformat folgen die Bezeichnungen so nicht.

Nur bei Open-ZFS wie OmniOS, nicht bei Solaris und Original ZFS

Bei mir kommt OmniOS zum Einsatz, also müsste -w klappen. Habe ich bisher ja auch so gemacht. Rekursiv werde ich dann nicht machen, da ich nicht alles auf den Backup-Server schieben will.

 

[gea]

Bzgl. des Basis-Snaps muss ich noch einmal nachfragen. Wird da eine bestimmte Nomenklatur vorausgesetzt, wie die Snaps bezeichnet sein müssen? Oder müssen die einfach gleich heißen? Einen Zeitstempel habe ich in den Snaps i.d.R. schon, aber Deinem Beipsielformat folgen die Bezeichnungen so nicht.

Ein Snapname eines Replikationsjobs enthält Quelle bzw Ziel, "_repli_", die jobid und eine laufende Nummer. Alle Replikationssnaps kann man auf beiden Servern listen wenn man nach repli filtert, die Snaps eines Jobs wenn man nach der Jobid filtert. Snaps auf beiden Seiten mit gleicher Jobid und laufender Nummer können als identischer Basissnap für eine weiterlaufende inkrementelle Replikation dienen.

 

[kandamir]

Okay, danke! Das trifft so nicht auf die Snapshots zu, die ich bisher von Hand per zfs send/receive übertragen habe. D.h. ich muss wohl mit einer kompletten Basisübermittlung arbeiten. Oder kann ich einfach auch von Hand einen Snapshot so benennen, übertragen und dann darauf die Replikation starten? Es geht um größere Datenmengen und ich wollte eigentlich vermeiden, alles komplett auf mal über die Internetleitung übertragen zu müssen. Selbst bei 40 MBit Upload, die mir derzeit zur Verfügung stehen, würde das ewig dauern…

 

[AliManali]

Andere Möglichkeit wäre noch, dass ich die Backup vmdk direkt an die Plesk VM hänge. Soweit hatte ich noch gar nicht überlegt.

So habe ich es nun gemacht. Backup auf die lokale vmdk und zusätzlich noch über sftp. Sicher ist sicher. Weil hatte gestern vor dem basteln alle Backups gelöscht, und es nacher hin gekriegt, das Panel ganz abzuschiessen. chown / statt ./ hat mich jene Stunden gekostet. Hatte nur noch ein altes Backup auf Storage Ebene. Aber jetzt läuft alles wieder. Und wird dreifach gesichert.

 

[kandamir]

@gea: Nochmal wegen der Repikation: es müsste doch eigentlich möglich sein, auf Quelle und Ziel den letzten gemeinsamen Snapshot über zfs rename entsprechend der geforderten Nomenklatur umzubenennen, damit nicht die kompletten nochmals übertragen werden müssen. Oder?

 

[gea]

Kein Problem wenn die Snaps auf beiden Seiten exakt identischen Stand haben und die lediglich anders heißen weil man die z.B. über eine manuelle Replikation außerhalb von napp-it angelegt hat.

 

[gea]

Den OpenSource Solaris Fork OmniOS gibt es in ein paar Tagen in der neuen LTS Version 151046

omnios-build/ReleaseNotes.md at rn · citrus-it/omnios-build

Build system for OmniOS. Contribute to citrus-it/omnios-build development by creating an account on GitHub.

github.com

Testen kann man den release candidate bereits jetzt mit folgendem Repository
(Jede OmniOS Version hat ein eigenes Repository, ein Grund für dessen Stabilität)

https://pkg.omnios.org/r151046/rc (omnios)
https://pkg.omnios.org/r151046/extra (extra.omnios)
bzw als iso

https://downloads.omnios.org/media/r151046/.rc/

Neben diversen Neuerungen wurde der ls Befehl an die Besonderheit des in Solaris eingebauten SMB Servers angepasst. Der nutzt ja als Owner /Creator Referenz nicht die Unix uid/gid sondern direkt die Windows AD SID als Dateiattribut. Damit bleiben Windows AD ACL nach einem Backup/Restore erhalten ohne dass man irgendwelche Mappings anpassen muss.

In obiger Darstellung gibt es eine Datei 1.txt die von root angelegt wurde. ein ls -l zeigt das. Die Datei 2.txt wurde von einem Active Directory Benutzer angelegt (Windows und OmniOS in AD). Ein ls -l zeigt nun direkt den AD Benutzer als Eigentümer und ein ls -n die zugehörige Windows SID. Ein ls -nn zeigt die (ephemerische) Unix uid/gid. Für ein Unix mit dem UNIX Dateisystem ZFS eine absolute Besonderheit. Windows zeigt mit Eigenschaft > Sicherheit > Erweitert > Eigentümer exakt die gleiche Info. Sun hatte das so gemacht um mit seinem SMB Server ein Verhalten ähnlich eines Windows Servers mit einem ntfs Dateisystem zu erreichen bei dem die Benutzeridentifikation weltweit eindeutig ist. Eine Unix uid wie 102 ist nicht eindeutig. Eine Windows SID ist einzigartig da die Dömäne Teil der Kennung ist.

update:
Vom der rc Version kann man später auf die Final Version updaten.

 

[automatenraum]

Requests/Fragen zum neuen Feature: ZFS autosnaps und ZFS replication bei ESXi/NFS Dateisystemen mit ESXi hot memory snaps.

1. Ist es möglich die ESXi Snaps nur auf bestimmte virtuelle Machinen einzuschränken und nicht global auf alle?
2. Wenn ich einen Snap Job einrichte, werden ALLE Snapshots der virtuellen Machinen entfernt, also auch manuell erstellte
Kann man das bitte konfigurierbar machen, dass wahlweise nur der erstellte Autosnap wieder gelöscht wird und nicht alle Snapshots entfernt werden?

 

[gea]

Requests/Fragen zum neuen Feature: ZFS autosnaps und ZFS replication bei ESXi/NFS Dateisystemen mit ESXi hot memory snaps.

1. Ist es möglich die ESXi Snaps nur auf bestimmte virtuelle Machinen einzuschränken und nicht global auf alle?
2. Wenn ich einen Snap Job einrichte, werden ALLE Snapshots der virtuellen Machinen entfernt, also auch manuell erstellte
Kann man das bitte konfigurierbar machen, dass wahlweise nur der erstellte Autosnap wieder gelöscht wird und nicht alle Snapshots entfernt werden?

Prinzipiell ist alles möglich.
Die Frage ist nur ob es Sinn macht oder das Script unnötig kompliziert wird, z.B.

1. Warum sollte man das einschränken wollen? Im Ergebnis hätte man VMs auf NFS die man mit hoher Wahrscheinlichkeit aus dem ZFS Snap sauber wiederherstellen kann und andere für die das nicht gilt. Schwierig das im Nachhinein zu trennen. Wenn man Performanceprobleme für laufende VMs befürchtet (die werden kurz angehalten), so wäre quiesce statt memory die sinnvolle Snap-Option. Da ist die Wartezeit viel geringer und zumindest das Dateisysten bleibt ok (braucht dafür VMware Tools). Ich halte es für sinnvoller wenn grundsätzlich alle ZFS VM Snaps einen sicheren ESXi Stand haben. Auch alle ESXi Backupprogramme setzen zumindest auf quiesce und ich werde das auch per default so machen und das deutlich langsamere hot memory nur als Option. Der Sinn ist ja gerade ZFS Snaps als vollwertiges ESXi Backup/Restoreverfahren zu haben.

Wenn man das aber auf einige VMs beschränken will, wäre es naheliegender zwei NFS Dateisysteme zu nutzen, eins mit ESXi Snaps und eins ohne. Das müsste ich aber noch untersuchen ob das sauber geht.

2. ESXi Snaps können sehr viel was Backup/Restore angeht, sind aber in ihrer Menge/Dauer arg beschränkt. Die strikte Regel lautet nie mehr als 32 ESXi Snaps für nicht mehr als 72 Stunden und selbst dann hat man Performanceprobleme zu erwarten. Die Idee der integrierten Snaps bedeutet ja gerade, dass man so viele wiederherstellbare ZFS Snaps haben kann wie man möchte. Wenn man also einen eigenen ESXi Snap außer der Reihe braucht, ist es sinnvoller den Autosnap Job manuell zu starten um dann den gewünschten ESXi Snap darin zu halten. Auch könnte man zwei Autosnap Jobs anlegen, einen mit quiesce une einen mit hot memore - eventuell mit manuellem Start. Aus dem Grund bevorzuge ich auch das generelle Entfernen aller ESXi Snap nach dem ZFS Snap zumal man dann den removeall Befehl nutzen kann der keine Zeitprobleme verursachen kann im Gegensatz zum fortlaufenden Löschen einzelner Snaps.

Der letzte Grund ist entscheidend. Wenn man alle VMs auf NFS nimmt, muss man nur SSH konfigurieren und beim Snap Job die ESXi ip angeben. Der Rest geht automatisch. Die Alternative wäre dann ein "other Job" mit einer Auflistung der Befehle für einzelne VMs wie ssh -l root 192.168.2.48 vim-cmd vmsvc/snapshot.create vmid snapname um Snaps einzeln anzulegen dann ein zfs create snap und dann entsprechende Löschbefehle für einzelne Snaps oder ssh -l root 192.168.2.48 vim-cmd vmsvc/snapshot.removeall vmid. Dann könnte man das ganz individuell beeinflussen.

Update:
Ich werde es wohl so konfiguriren: Ein ZFS Autosnap erzeugt vorab einen ESXI Snap und löscht nacher nur den letzten.
Frühere ESXi Snaps bleiben erhalten und müssen manuell gelöscht werden. Jeder weiß ja was er warum tut.


Angedacht ist im Moment: Alle ZFS/NFS Snaps mit VMs sind sauber wiederherstellbar über

 

[automatenraum]

Hallo beim ersten Punkt bin ich nachdem ich nochmal darüber nachgedacht habe voll bei dir.

Zum zweiten Punkt, es gibt ja gute Gründe, warum man manuell Snapshots anlegt, Entwicklungssysteme, Tests, etc., daher bin ich dankbar, wenn das jetzt anders gelöst wird.

Vielen Dank und Grüße

Beitrag automatisch zusammengeführt: 23.04.2023

Mir ist gerade noch was aufgefallen:

wenn ich ein Nappit-Update mache, wird jedesmal "Advertise SMB Shares" auf disabled gesetzt und ich muss es manuell wieder aktivieren...

 

[gea]

Beitrag automatisch zusammengeführt: 23.04.2023

Mir ist gerade noch was aufgefallen:

wenn ich ein Nappit-Update mache, wird jedesmal "Advertise SMB Shares" auf disabled gesetzt und ich muss es manuell wieder aktivieren...

Ein Update muss sicherheitshalber alle von napp-it gestarteten Hintergrunddienste beenden weil sich da was geändert haben könnte. dazu gehört auch Bonjour/dns-sd.
Da es dazu einige Entwicklungen auch für Windows gibt (eventuell künftig OS Service unabhängig von napp-it) würde ich da momentan ungern was ändern.

 

[Luckysh0t]

Ich werde es wohl so konfiguriren: Ein ZFS Autosnap erzeugt vorab einen ESXI Snap und löscht nacher nur den letzten.

Wäre es nicht sicherer den snap zb namensbasiert (zb nappitautosnap) zu löschen ? So steht und fällt das ganze mit der Häufigkeit am Tag und blödes timing ob in der Zwischenzeit ein weitere snap als neuer „letzter“ dazu kommt.

 

[automatenraum]

Nappit kann ja gerne vorm Update alle Hintergrunddienste stoppen, aber nach dem Update sollte der Stand von vorm Update dann auch wieder herhestellt werden, sprich wenn "Advertise" aktiv war, den Dienst dann auch wieder starten.
Bonjour wird nach dem Update ja auch wieder gestartet wenns aktiv war...

 

[gea]

Ein Problem mit Bonjour advertizing konnte ich nicht nachvollziehen. Reboot, downgrade, upgrde (21.06, 23.01, 23.dev) führte bei mir immer dazu dass die letzte dns-sd Einstellung aus Service > Bonjour wiederhergestellt wurde. Dazu wird jeweils /var/web-gui/_log/bonjour.sh neu gestartet.

 

[automatenraum]

Komisch, bei mir ist nach einem Update von Nappit immer "Advertise SMB Shares" auf Disabled gesetzt und ich muss es manuell wieder aktivieren.

 

[gea]

Die Apple Erkennung für SMB Shares, die Darstellung des OmniOS SMB Servers als Xserve und Timemachine via SMB basiert auf mdns und dns-sd
und wird über die /var/web-gui/_log/bonjour.sh gestartet. Darin sollte stehen (omnisan ist hostname, timecapsule ist SMB share für Timemachine)

#!/usr/bin/bash
/usr/bin/dns-sd -R "omnisan" _smb._tcp local 445 &
/usr/bin/dns-sd -R "omnisan" _device-info._tcp local 445 model=Xserve &
/usr/bin/dns-sd -R "omnisan" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' 'dk0=adVN=timecapsule,adVF=0x82' &

Nach dem Start der Datei (boot, upgrade, downgrade) sollten drei dns-sd Hintergrunddienste laufen:
ps axw | grep dns-sd
28473 ? S 0:00 /usr/bin/dns-sd -R omnisan _smb._tcp local 445
28474 ? S 0:00 /usr/bin/dns-sd -R omnisan _device-info._tcp local 445 model=Xserve
28475 ? S 0:00 /usr/bin/dns-sd -R omnisan _adisk._tcp local 445 sys=waMa=0,adVF=0x100 dk0=adVN=timecapsule,adVF=0x82

 

[automatenraum]

Hab Enable Time Machine Support und Advertise SMB Shares nochmal aktiviert und Update gemacht, nach dem Update ist beides wieder auf Disabled.

Zuerst dachte ich es liegt evtl. an meinen zusätzlichen manuellen Eintragungen in der bounjour.sh, hab die dann mal vor und testweise nach den folgenden drei Einträgen gesetzt und dann auch nur mit den drei Einträgen getestet ohne meine Dienste, immer das gleiche Ergebnis, nach Update Disabled.

/usr/bin/dns-sd -R "fileserver" _smb._tcp local 445 &
/usr/bin/dns-sd -R "fileserver" _device-info._tcp local 445 model=Xserve &
/usr/bin/dns-sd -R "fileserver" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' 'dk0=adVN=Time-Machine,adVF=0x82' &

 

[automatenraum]

Das Problem liegt glaube ich woanders, wenn ich unter Apache https das Update mache, scheint das was zu klemmen, das Update scheint da nicht sauber durchzulaufen. Daher werden die Dienste nicht mehr aktiviert. Mache ich das Update unter dem alten mini_httpd läuft alles sauber durch und die Dienste werden auch aktiviert.

 

[gea]

In der Tat. Up/ Downgrade unter Apache startet anschließend nicht alle Dienste sauber.
Ich muss da was im Startprozess ändern.

update:
ok, auch Apache https sollte jetzt ein sauberes reload machen.

 

[gea]

Der neue minimalistische Solaris fork OmniOS r151046 long term stable (Unix) ist da

Release Notes

illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support

omnios.org

Open-ZFS in seiner ursprünglichen Solaris Umgebung
Beste Integration von ZFS ins Betriebssystem mit Bootenumgebungen für problemlose Up/Downgrades und niedrigstem Resourcenverbrauch für ZFS.

OpenSource aber mit einer kommerziellen Support Option
Regelmäßige Sicherheits und Bugfix Updates sind frei.

Release Schedule

illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support

omnios.org

Eine eigenes Softwaresammlung per Stable Release.
Keine unerwartet neuen Eigenschaften oder geänderten Verhaltensweisen, nur regelmäßige Sicherheits und Fehlerupdates.
Updaten kann man ab der letzten r151038 LTS durch Wechsel des Repository, pkg update und reboot.

https://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf

Fileservices wie FC/iSCSI, kernelbasiertes NFS und multithreaded SMB sind Teil des Solaris Betriebssystems
mit einer perfekten Integration von Windows ntfs ACL mit direkter Nutzung von Windows AD SID um SMB Dateirechte im Backup zu erhalten, lokalen Windows SMB Gruppen und ZFS Snaps als Windows previous versions ohne extre Konfiguration. Einfachstes SMB Setup (keine samba.cfg), einfach iSCSI/ NFS oder SMB für ein ZFS Dateisystem ein oder ausschalten.

Update:
Ein ready to use ESXi .ova ZFS Server Template mit OmniOS 151046lts und napp-it.dev mit Perl module für TLS and SOAP zum freien Download

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Downloads

napp-it.org - ZFS NAS SAN Server mit einer durch den Benutzer anpassbaren Weboberfläche // All In One server = virtualisierter lauffähiger ZFS-Server

www.napp-it.org

 

[asche77]

Hallo @gea, kann es sein dass die email-Funktionen (email jobs) in der Free-Version gesperrt sind?

Ich kann seit ca. Anfang dieses Jahres keine Status- oder alert-emails mehr verschicken, keine neuen email jobs anlegen und auch nicht TLS email an- oder ausschalten (gibt keine Menü-Einträge dafür).

Früher ging TLS über smtp.gmail.com prima, dann irgendwann (Januar 2023?) nicht mehr.

Unter about -> settings -> notification settings kann ich zwar einen lokalen SMTP relay einstellen, und der wird dann von Jobs -> email -> smtp-test auch erfolgreich genutzt, aber nicht von den bestehenden alert/status jobs die weiterhin eigene, dort eingegebene und nicht vollständig editierbare SMTP-Einstellungen haben (nämlich smtp.gmail.com:587 etc.)

Die sendmail-services sind "disabled" und lassen sich auch nicht aktivieren. Nach einem "pkg install sendmail" lassen sich beide sendmail-services aktivieren und zeigen "online". Status/Alert geht dennoch nicht. Der "status" Job zeigt trotz "run now" weiterhin das letzte Ausführungsdatum im Januar.

menu ist auf "en" gestellt.

 

[gea]

Das ist ein Bug, ich kümmere mich darum

ps
sendmail ist normalerweise nicht installiert und wird auch nicht genutzt sondert die Perl SSL/TLS Module

Update:
Beim Test des Mail scripts auf der Konsole kommt (mit der jobid)

perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/job-email.pl run_1674494647
## send job email 78 me@mail.org
job-email 67 to me@mail.org
Couldn't start TLS: hostname verification failed

Das Problem ist beseitigt im aktuellen napp-it und napp-it free 21.06a12

 

[asche77]

21.06a12: menus sind wieder da (danke!), TLS (test) wirft aber weiter Fehlermeldungen aus:

Couldn't start TLS: hostname verification failed at /var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl line 80.

ABER: Status Mail job (mit TLS) geht wieder!

 

[gea]

Die Testfunktion habe ich übersehen,
nochmal die free laden, dann sollte auch TLS Test gehen

Beitrag automatisch zusammengeführt: 04.05.2023

The illumos security team have today published a security advisory concerning CVE-2023-31284, a kernel stack overflow that can be performed by an unprivileged user, either in the global zone or in any non-global zone. A copy of their advisory is below.


ACTION: If you are using any of the supported OmniOS versions, see below, (or the recently retired r42), run pkg update to upgrade to a version that includes the fix. Note, that a reboot is required. If you have already upgraded to r46, then you are all set as it already includes the fix.


The following OmniOS versions include the fix:

Release Notes

illumos based server OS with ZFS, DTrace, Crossbow, SMF, Bhyve, KVM and Linux zone support

omnios.org

• r151046
• r151044y
• r151042az
• r151038cz

If you are running an earlier version, upgrade to a supported version (in stages if necessary) following https://omnios.org/upgrade.



##########################
--- illumos Security Team advisory ---


We are reaching out today to inform you about CVE-2023-31284. We have pushed a commit to address this, which you can find at
https://github.com/illumos/illumos-gate/commit/676abcb77c26296424298b37b96d2bce39ab25e5. While we don't currently know of anyone exploiting this in the wild, this is a kernel stack overflow that can be performed by an unprivileged user, either in the global zone, or any non-global zone.

The following details provide information about this particular issue:

IMPACT: An unprivileged user in any zone can cause a kernel stack buffer overflow. While stack canaries can capture this and lead to a denial of service, it is possible for a skilled attacker to leverage this for local privilege escalation or execution of arbitrary code (e.g. if combined with another bug such as an information leak).


ACTION: Please be on the look out for patches from your distribution and be ready to update.


MITIGATIONS: Running a kernel built with -fstack-protector (the illumos default) can help mitigate this and turn these issues into a denial of service, but that is not a guarantee. We believe that unprivileged processes which have called chroot(2) with a new root that does not contain the sdev (/dev) filesystem most likely cannot trigger the bug, but an exhaustive analysis is still required.

Please reach out to us if you have any questions, whether on the mailing list, IRC, or otherwise, and we'll try to help as we can.

We'd like to thank Alex Wilson and the students at the University of Queensland for reporting this issue to us, and to Dan McDonald for his work in fixing it.

The illumos Security Team

 

[MisterY]

Ich hatte vorhin ein Befehl benutzt, der mir die Belegung der einzelnen Datenträger im zpool angezeigt hatte. Aber leider in Screen, deshalb zeigt history nichts an. Kennt den jemand?

 

[zos]

Ich hatte vorhin ein Befehl benutzt, der mir die Belegung der einzelnen Datenträger im zpool angezeigt hatte. Aber leider in Screen, deshalb zeigt history nichts an. Kennt den jemand?

Vielleicht „zpool list -v“?

 

[gea]

Ist sicher das die Anzeige per Datenträger (=Einzelplatte) erfolgte?
ZFS zeigt Informationen per pool oder vdev, nicht per Platte (außer man hat Basic vdevs aus Einzelplatten)

 

[bbott]

Sollte das hinzufügen weiterer Datenträger zu einem Pool nicht per "zpool attach" ermöglicht werden (FreeBSD https://freebsdfoundation.org/blog/raid-z-expansion-feature-for-zfs/)? Für Ubuntu wird es auch https://manpages.ubuntu.com/manpages/impish/man8/zpool-attach.8.html dokumentiert, obwohl es noch nicht für ZFS offiziell released ist? Oder ist es nun inzwischen Verfügbar? Hat jemand ein Update???