[Sammelthread] ZFS Stammtisch

[JohnnyBGoode]

Danke, Bzzz für die Bestätigung, dass die Karte zumindest keine Probleme machen sollte!

Spricht etwas bei Solaris dagegen, es mit UEFI/CSM disabled/Secure Boot zu installieren oder ist das eine eher doofe Idee? Der verwendete HBA (Broadcom 9400 8i8e) kann alles, soll aber auch nur für die nicht-OS-Datenlaufwerke herhalten.

 

[kandamir]

Hallo,

ich habe folgendes Problem: mein Napp-It läuft virtualisiert unter ESXi 6.5. Ich wollte ESXi updaten und habe alle VMs runtergefahren. Die Napp-It VM habe ich zumm Schluss herunter gefahren (habe es mir einfach gemacht und am ESXi Web über VMs => SAN (so heißt die VM) => Aktionen => Gastbetriebssystem => herunterfahren ausgewählt. Etwas überraschend ist die VM gleich wieder gestartet und mit einem Fehler hängen geblieben.

Es erscheint die Meldung:

san console login: cannot mount '/Data': directory is not empty
svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount -a failed: exit status 1
Oct 10 12:37:01 svc.startd[10]: svc:/system/filesystem/local:default: Methhod "/lib/svc/method/fs-local" failed with exit status 95.
Oct 10 12:37:01 svc.startd[10]: system/filesystem/local:dafault failed fatally: transitioned to maintenance (see 'svcs -xv' for details)

svcs -xv ergibt dann Folgendes:

root@san:~# svcs -xv
svc:/system/filesystem/local:default (local file system mounts)
 State: maintenance since Thu Oct 10 12:37:01 2019
Reason: Start method exited with $SMF_EXIT_ERR_FATAL.
   See: http://illumos.org/msg/SMF-8000-KS
   See: /var/svc/log/system-filesystem-local:default.log
Impact: 23 dependent services are not running:
        svc:/network/nfs/status:default
        svc:/network/nfs/nlockmgr:default
        svc:/network/nfs/server:default
        svc:/milestone/multi-user-server:default
        svc:/system/zones:default
        svc:/milestone/multi-user:default
        svc:/system/intrd:default
        svc:/system/virtualization/open-vm-tools:default
        svc:/system/system-log:default
        svc:/network/smtp:sendmail
        svc:/network/sendmail-client:default
        svc:/system/filesystem/autofs:default
        svc:/system/dumpadm:default
        svc:/system/fmd:default
        svc:/network/inetd:default
        svc:/system/cron:default
        svc:/system/hotplug:default
        svc:/network/shares/group:default
        svc:/network/smb/server:default
        svc:/network/shares/group:smb
        svc:/network/shares/group:zfs
        svc:/system/boot-archive-update:default
        svc:/system/sac:default

svc:/network/rpc/gss:default (Generic Security Service)
 State: uninitialized since Thu Oct 10 12:36:56 2019
Reason: Restarter svc:/network/inetd:default is not running.
   See: http://illumos.org/msg/SMF-8000-5H
   See: man -M /usr/share/man -s 1M gssd
Impact: 11 dependent services are not running:
        svc:/network/smb/client:default
        svc:/milestone/multi-user:default
        svc:/system/intrd:default
        svc:/milestone/multi-user-server:default
        svc:/system/zones:default
        svc:/system/virtualization/open-vm-tools:default
        svc:/network/smb/server:default
        svc:/network/shares/group:default
        svc:/network/nfs/server:default
        svc:/network/shares/group:smb
        svc:/network/shares/group:zfs

svc:/network/rpc/smserver:default (removable media management)
 State: uninitialized since Thu Oct 10 12:36:57 2019
Reason: Restarter svc:/network/inetd:default is not running.
   See: http://illumos.org/msg/SMF-8000-5H
   See: man -M /usr/share/man -s 1M rpc.smserverd
Impact: 2 dependent services are not running:
        svc:/milestone/multi-user-server:default
        svc:/system/zones:default

root@san:~# less /var/svc/log/system-filesystem-localefault.log

[ Oct 10 12:36:56 Enabled. ]
[ Oct 10 12:37:00 Executing start method ("/lib/svc/method/fs-local"). ]
WARNING: /usr/sbin/zfs mount -a failed: exit status 1
[ Oct 10 12:37:01 Method "start" exited with status 95. ]

Das Verzeichnis "/Data" ist tatsächlich nicht leer, weil die Dateisysteme des Pools "Data" tatsächlich schon gemountet zu sein scheinen. Das Napp-It Frontend ist nicht erreichbar, per ssh komme ich zumindest auf die Maschine.

Was ist zu tun, damit Napp-It wieder fehlerfrei startet? Was wird noch an Infos benötigt? Unschwer zu erraten, dass das sehr ungelegen kommt, da damit mein zentraler Filer down ist...

Wäre nett, wenn mir jemand helfen könnte...

Danke und Gruß

Kandamir

 

[gea]

Ich würde auf der Konsole erst mal schauen, welche Dateisysteme gemountet sind,
bzw den Pool Data optional exportieren
zpool export -f Data

Dann mit mc den Midnight Commander starten (oder den Filer mit winscp verbinden).
Wenn es jetzt noch einen Ordner /Data gibt, so handelt es sich um einen einfachen Ordner, kein Dateisystem. Den Löschen (falls nichts wichtiges drin ist) oder umbenennen.

dann Pool Data wieder importieren
zpool import Data (oder das später in napp-it machen)

Wenn das Problem dadurch entstand, dass der Pool Data nicht importiert werden konnte, weild es einen nicht-leeren Ordner gleichen Namens gab, so sollte das Problem behoben sein.

Jetzt einfach VM neustarten (oder napp-it per /etc/init.d/napp-it restart)


Ganz allgemein bei Problemen:
- Entweder ein früheres BE booten bei dem das Problem noch nicht bestand oder
- Napp-it per wget neu installieren. Einstellungen bleiben erhalten.

Bei der Neuinstallation würde ein Importproblem aber weiterbestehen.


In ganz schlimmern Fällen ohne funktionierendes BE
VM neu bereitstellen und Pool importieren.

 

[Elektromat]

Servus,

mich würde interessieren, ob es einen Weg gibt mir die ACL on Folder Permissions wie auch die ACL on SMB Folder per ssh oder in ein File auszugeben.
Gibt es hierzu ein passendes Script/Befehl? Und oder evtl. sogar ne Auflistung mit welchem befehl ein ändern möglich wäre?
Wäre super um besser zu sehen, wer was zu welchem Folder darf.

Grüße
Elektromat

 

[gea]

Anzeige der ACL
ls -v /pfad

Setzen von ACL
/bin/chmod

Suchen
find

Ausgabe in Datei
> /pfad/dateiname


Zusammen sowas wie
ls -dv `find /var -type d` > /root/ordneracl.txt

 

[kandamir]

Danke, @gea! Export, Import und Reboot haben geholfen! Das werde ich mir wohl mal merken müssen, dass Export/Import ein probates Hilfsmittel für solche Situationen sein können. Die Dateisysteme des Pools waren tatsächlich vorher schon gemountet, keine Ahnung, weshalb das Probleme gemacht hatte. Jetzt get's auf jeden Fall wieder. Besten Dank!

 

[Haithabu84]

Mir ist gerade aufgefallen, dass einem der OmniOS-Installer überhaupt keine Möglichkeit der Partitionierung einräumt. Schlecht.

Somit wird über die gesamte Platte der rpool gelegt. Ein vorherige Partitionierung wird ignoriert. Gibt es da noch einen anderen Weg?

 

[martingo]

Grundsätzlich ist das der Gedanke dahinter, macht Solaris auch nicht anders. Oder Proxmox. Platten werden dem Pool zugeordnet und die Datasets können dann beliebig groß sein bis eben Quota oder Plattenende erreicht ist.

Was willst Du denn partitionieren? Für slog/larc usw.?

 

[snipor]

Ich bin mir nicht sicher, ob OmniOS 151031 bloody bereits einen neuen NVMe Treiber enthält. Ist aber wahrscheinlich, da OmniOS NVMe hotplug für die nächste Stable für November angekündigt hat. Ein Versuch wärs wert. Dank BE kann man ja zurück oder dann auf 151032 stable updaten.

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

Ansonsten mal abwarten ob es eine Reaktion in illumos-discuss gibt.

Leider gab es bisher keine neue Information, nur ein User der wohl ebenfalls schon sehr lange Probleme damit hat.
Es scheint also wohl doch einen Zusammenhang hiermit zu geben. Bug #7723: disable MSI-X in nvme on VMware - illumos gate - illumos
Das wird also wohl auch in absehbarer Zeit nicht funktionieren. Was mich nur wundert, warum gibt es Typen die funktionieren und solche, wie die P4600 oder 4510, die nicht laufen.

 

[Haithabu84]

Was willst Du denn partitionieren? Für slog/larc usw.?

Korrekt. In erster Linie wollte ich SLOG mit drauf machen. Brauche nicht die Mega-Leseperformance.

 

[martingo]

Entweder eierst Du mit nachträglich Pool verkleinern rum oder Du installierst erstmal auf eine kleinere (temporäre) Platte (oder Stick/SD).
Dann partitioniert Du die eigentliche Platten wie gewünscht und fügst die zukünftige Partition als Mirror hinzu und entfernst danach die temporäre Platte.
Das wäre ein schnell machbarer Workaround.
Anschließend autoexpand=on und ggf. Mirror hinzufügen.

Alternativ gibt es unter OmniOS vielleicht einen Advanced Installer (Bootmenü) der einem mehr Möglichkeiten einräumt oder einzelne Schritte manuell per Konsole erledigen lässt.

 

[gea]

Man könnte auch mit einem USB Stick mit parted magic oder Hiren's booten und die Platte vorher partitionieren und dann installieren. Solarish will halt als Default für ZFS immer ganze Platten. Eventuell kann man auch auf der Konsole mit fdisk arbeiten.

Ein Slog zusätzlich auf der Bootplatte ist aber nicht gerade "suggested use" und wenn es sich bei der Bootplatte nicht gerade um eine Optane handelt vermutlich auch nicht performant. Wenn die Bootplatte keine Powerloss Protection hat auch nicht sicher.

 

[martingo]

Er sagt ja, dass das eben nicht ging. Zumindest lese ich es so heraus, dass er nur ganze Platten als Ziel auswählen konnte.

Über Sinn oder Unsinn habe ich mich jetzt nicht ausgelassen.

 

[gea]

Gibt es eine Möglichkeit eine nvme SSD (P4510) welche über ESXi (6.7U3) mittels pass-through durchgereicht wird in napp-it zum Laufen zu bekommen? Wird leider gar nicht erkannt.

Ich habe gerade gesehen, dass OmniOS einenPatch bereitstellt damit diese Serie Intel NVMe unter ESXi als pass-through gehen sollen.
Falls dieser in OmniOS 151032 landen sollte, würde das bedeuten dass damit Pass-through erst ab ESXi 6 funktioniert.
Könnte also für alle interessant sein.

Topicbox

 

[gea]

ZFS Feature Allocation Classes

Ich habe ein paar Tests damit unter OmniOS gemacht,
siehe http://napp-it.org/doc/downloads/special-vdev.pdf

Ergebnis: Ein tolles neues Feature.
Damit kann man per ZFS Dateisystem bestimmen, ob die Daten auf dem normalen langsamen Pool oder dem schnelleren special vdev landen sollen.


btw
Special vdev soll man entfernen können. Ich habe das in der OmniOS bloody getested. Mir ist dabei das OS abgestürzt und der Pool war korrupt. Also noch kein Feature für einen Produktionsserver. Da eventuell noch etwas warten.

 

[snipor]

Nachdem ich es als Bug gemeldet und darum gebeten hatte einen Treiber mit (re)aktivierter MSI-X Funktion zu bekommen hat sich tatsächlich ein Entwickler gefunden der mir sofort einen einen entsprechenden Treiber erstellt hat.
Mit diesem Treiber sieht es bisher echt gut aus, bin da gerade noch beim Testen.

Da ich durch die ganze herumprobiererei mittlerweile auf einem 2. System napp-it mit dem aktuellen Template von gea aufgesetzt habe, habe ich nun auch wieder 30 Tage die Pro Features freigeschaltet.
Jetzt wollte ich mal die Replication testen.
Habe auf dem 2. System bei welchem die noch Features aktviert sind das bestehende napp-it System eingebunden und einen Job erstellt. Leider klappt das nicht so recht.
Muss ich hier noch etwas beachten?

 

[Haithabu84]

Man könnte auch mit einem USB Stick mit parted magic oder Hiren's booten und die Platte vorher partitionieren und dann installieren. Solarish will halt als Default für ZFS immer ganze Platten. Eventuell kann man auch auf der Konsole mit fdisk arbeiten.

Ein Slog zusätzlich auf der Bootplatte ist aber nicht gerade "suggested use" und wenn es sich bei der Bootplatte nicht gerade um eine Optane handelt vermutlich auch nicht performant. Wenn die Bootplatte keine Powerloss Protection hat auch nicht sicher.

Es wären WD SS DC 530 SAS SSD gewesen.

Ok. Dann kann ich also als Boot-Partition auch stink-normale SSDs aus dem Consumer-Bereich nehmen... die werden doch ansonsten für nichts anderes verwendet als das OS zu laden und Einstellungen zu speichern? Da brauche ich dann auch kein Power-Loss, oder sehe ich das falsch? Dann würde ich nämlich jetzt einfach paar günstige Samsung EVOs nehmen, oder gleich auf einem USB-Stick installieren... oder ist dies ebenfalls nicht "suggested use"?

Danach dann separat die WD 530er als SLOG.

 

[asche77]

@Haithabu84:
1. consumer SSD für den rpool sollte im Regelfall OK sein.
2. Du kannst Dein Vorhaben auch über den Virtualisierungs-Umweg gehen (ESXi, ProxMox, whatever):
- SSD in zwei virtuelle disks spalten
- beide als virtuelle disks der OmniOS VM zuweisen
- eine als rpool, eine als SLOG bestimmen

Vorher würde ich mir halt nochmal Gedanken machen, ob Du überhaupt ein SLOG brauchst.

 

[Haithabu84]

@Haithabu84:
1. consumer SSD für den rpool sollte im Regelfall OK sein.
2. Du kannst Dein Vorhaben auch über den Virtualisierungs-Umweg gehen (ESXi, ProxMox, whatever):
- SSD in zwei virtuelle disks spalten
- beide als virtuelle disks der OmniOS VM zuweisen
- eine als rpool, eine als SLOG bestimmen

Vorher würde ich mir halt nochmal Gedanken machen, ob Du überhaupt ein SLOG brauchst.

Umweg über Virtualisierung bin ich kein Freund von. Lieber Bare-Metal: einfacher, sicherer und performanter.

Des weiteren will ich die Platten im OS direkt ansteuern. Da hat Proxmox so seine Probleme beim durchreichen von Hardware, dass will ich mir echt nicht geben. ESXi fällt aus, da ich es kommerziell nutze und ich dafür eine Lizenz benötige.

 

[MisterY]

Ich hatte noch nie Probleme Hardware in Proxmox durchzureichen.

 

[gea]

Nachdem ich es als Bug gemeldet und darum gebeten hatte einen Treiber mit (re)aktivierter MSI-X Funktion zu bekommen hat sich tatsächlich ein Entwickler gefunden der mir sofort einen einen entsprechenden Treiber erstellt hat.
Mit diesem Treiber sieht es bisher echt gut aus, bin da gerade noch beim Testen.

Da ich durch die ganze herumprobiererei mittlerweile auf einem 2. System napp-it mit dem aktuellen Template von gea aufgesetzt habe, habe ich nun auch wieder 30 Tage die Pro Features freigeschaltet.
Jetzt wollte ich mal die Replication testen.
Habe auf dem 2. System bei welchem die noch Features aktviert sind das bestehende napp-it System eingebunden und einen Job erstellt. Leider klappt das nicht so recht.
Muss ich hier noch etwas beachten?

Die zfs receive Fehlermeldung "failed to read from stream" ist leider nicht besonders aufschlussreich. Das kann beideuten dass gar keine Daten empfangen werden, diese korrupt sind oder ein sonstiges Problem besteht.

Prinzipiell scheint die Appliance Gruppe ja zu funktionieren. Werden denn die ZFS Dateisysteme der Gegenstelle im Menü Ectensions > Appliance Group angezeigt wenn man auf ZFS klickt.

Kann es ein Netzproblem geben (mehrere Netzwerkkarten im gleichen Subnet, mehrere Einträge in der Appliance Group - dann auf beiden Seiten Members löschen und neu anlegen, ist Jumbo aktiv - macht gerne mal Probleme)

Sind die Pools auf beiden Seiten featuremäßig gleich?

- - - Updated - - -

Umweg über Virtualisierung bin ich kein Freund von. Lieber Bare-Metal: einfacher, sicherer und performanter.

Des weiteren will ich die Platten im OS direkt ansteuern. Da hat Proxmox so seine Probleme beim durchreichen von Hardware, dass will ich mir echt nicht geben. ESXi fällt aus, da ich es kommerziell nutze und ich dafür eine Lizenz benötige.

Wenn man vergleichbare CPU Leistung und RAM veranschlagt und HBA Pass-through nimmt, ist ein virtualisierter Storageserver fast so schnell wie Barebone. Virtualisiertes Netzwerk bremst manchmal wobei vmxnet3 unter ESXi schon gnadenlos gut ist. Ist aber kein Selbstzweck sondern ideal als "lokaler" Storage für VMs.

ESXi Free kann man auch kommerziell nutzen. Die Kaufversion hat dann halt Vcenter (zentrales Management vieler ESXi), Vsan (ZFS ist besser) oder Hot-Move von VMs.

Von USB Srick Boot halte ich wenig, selbst bei ESXi finde ich eine kleine SSD viel zuverlässiger und der Server booted einfach viel schneller. Beim US Laufwerk könnte man auf PLP verzichten. Ich bevorzuga aber auch da die kleinsten/billigsten Intel DC SSDs.

 

[snipor]

Die zfs receive Fehlermeldung "failed to read from stream" ist leider nicht besonders aufschlussreich. Das kann beideuten dass gar keine Daten empfangen werden, diese korrupt sind oder ein sonstiges Problem besteht.

Prinzipiell scheint die Appliance Gruppe ja zu funktionieren. Werden denn die ZFS Dateisysteme der Gegenstelle im Menü Ectensions > Appliance Group angezeigt wenn man auf ZFS klickt.

Kann es ein Netzproblem geben (mehrere Netzwerkkarten im gleichen Subnet, mehrere Einträge in der Appliance Group - dann auf beiden Seiten Members löschen und neu anlegen, ist Jumbo aktiv - macht gerne mal Probleme)

Sind die Pools auf beiden Seiten featuremäßig gleich?

- - - Updated - - -



Wenn man vergleichbare CPU Leistung und RAM veranschlagt und HBA Pass-through nimmt, ist ein virtualisierter Storageserver fast so schnell wie Barebone. Virtualisiertes Netzwerk bremst manchmal wobei vmxnet3 unter ESXi schon gnadenlos gut ist. Ist aber kein Selbstzweck sondern ideal als "lokaler" Storage für VMs.

ESXi Free kann man auch kommerziell nutzen. Die Kaufversion hat dann halt Vcenter (zentrales Management vieler ESXi), Vsan (ZFS ist besser) oder Hot-Move von VMs.

Von USB Srick Boot halte ich wenig, selbst bei ESXi finde ich eine kleine SSD viel zuverlässiger und der Server booted einfach viel schneller. Beim US Laufwerk könnte man auf PLP verzichten. Ich bevorzuga aber auch da die kleinsten/billigsten Intel DC SSDs.

Die ZFS Dateisysteme werden jeweils in der Gegenstelle problemlos angezeigt. Gelöscht und neu erstellt habe ich auch schon.

Pools sollten auch passend sein?





Oder muss das 2. System auch "Eval" statt "free" sein?

Sollte auf dem "Source" System nicht auch ein Snap unter Snapshots auftauchen?

 

[gea]

Bei einer Replikation wird auf dem Quellsystem bei einer Erstreplikation zuerst ein Snap ..nr1 angelegt. Dieser wird per zfs send übertragen. Die Quellsysteme können alle Free sein.

Die einzige Auffälligkeit ist dass der nvme Pool zu 91% voll ist. Eventuell mal testweise die 10% Reservierung im Menü ZFS Dateisysteme löschen oder verkleinern. Platzprobleme würden zwar eher auf dem Zielsystem zu Problemen führen aber dennoch. Alternativ auf dem nvme Pool ein Dateisystem "test" anlegen und das replizieren. Dann sollte Platz kein Problem sein.

Ansonsten auf beiden Seiten auf das aktuelle napp-it free/Pro updaten, auf beiden Seiten die Appliance Group Members löschen/ neu anlegen und eine Replikation eines einzelnen Dateisystems ohne Extras (dedup etc) starten.

Man kann dann die Logs überprüfen. Auf dem Zielsystem wird ja alles in Jobs gezeigt (bei replicate oder Datum). Auf dem Quellserver mal "Jobs > Remote Log" auf zfs send Einträge prüfen.

 

[snipor]

Quelle ist der SSDPool auf einem System mit napp-it Free. Ziel ist der NVMe-Pool auf einem neu aufgesetzten System, es sind also noch einige Tage die Pro Features verfügbar.
Der NVMe-Pool ist leer hier sollte sich nichts befinden, da ja die Replikation nicht geklappt hat. Aber Platz genug sollte sein.

 

[gea]

Ja, mein Fehler. Der NVMe Pool ist fast leer und Platz sollte kein Problem sein.

Ansonsten.
Die anderen Punkte nochmal durchgehen. Wenn die Gruppe funktioniert sollte Replikation kein Problem sein. Auf jeden Fall zunächst nur einen Job für ein einzelnes Dateisystem ohne besondere Replikations Einstellungen testen (recursiv, dedup, encrypted etc).

Eine Verlängerung der Pro Features ist auch kein Problem. Für einzelne Aktionen oder kurze Tests kann man auch einen Kurzzeitkey online beziehen unter napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Extensions

 

[snipor]

Auf beiden Systemen ist napp-it 18.12w3. Auch mit einem neuen, einzelnen Dateisystem geht es nicht.

Source Log


Destination Log


Die Einstellungen bei Replikation sind die Standardwerte, also keinerlei Features aktiv.

Auf dem Source System finde ich unter Snapshots auch keinen Snap der erzeugt wurde.

 

[gea]

An diesem Punkt wirds etwas schwierig.
Prinzipiell geben die Logs folgendes her

Der Receiver geht auf Empfang und startet remote den Send Prozess
Der Sender beginnt zu senden und sendet seinen kompletten Snap mit ca 3MB, allerdings mit extrem niedriger Performance in ca 5 Minuten.

Der Receive Prozess endet vorher mit "Failed to read from stream".
Ein Erfolgreiches Replizieren hinterläßt auf beiden Seiten einen Snap ..nr1.
Je nachdem wann das Problem auftritt wird auch der Quellsnap gelöscht.

Der genaue Ablauf ist etwas schwieriger zu diagnostizieren da eine ZFS Replikation arbeitet wie das Aufnehmen eines Liedes aus dem Radio. Bevor das Lied beginnt, drückt man Aufnahme und wenn das Lied endet stoppt die Aufnahme automatisch. Eine kurze Unterbrechung und die Aufnahme wird ohne weitere Diagnosemöglichkeit abgebrochen.

Prinzipiell arbeitet das Verfahren aber sehr zuverlässig und vor allem extrem schnell. Man hat zwar nicht die Transfer Kontrolle wie z.B. rsync das auf einem Datenvergleich basiert. Dafür kann nur die ZFS Replikation Arbeitsweise einen Petabyte Hochlastserver mit offenen Dateien fast in Echtzeit syncron mit einem Backupserver halten und dafür ist das zfs send Verfahren ja ausgelegt. Replikation zwischen Napp-it 18.12 läuft ansonst ohne Auffälligkeit.

Das beschriebene Verhalten ist jedenfalls so, dass ich erstmal beide Server neu starten würde. Geht es dann immer noch nicht, würde ich mal eine lokale Replikation mit mehr Daten versuchen. Klappt das sehe ich des Problem eher auf der Netzwerkseite. Die extrem schlechte Send-Performance spricht auch dafür. Die Übertragung sollte nahe bei der physikalischen Netz/Plattenperformance liegen und nicht bei 6 KiB/s. Das scheint aber gerade für die Fernsteuerung zu reichen.

Gibt es sonst eine Netzwerk Auffälligkeit oder Besonderheit?

 

[gea]

Update zu Open-ZFS Allocation Classes
(Das sind spezielle vdevs für die dedup Tabelle, Metadaten, kleine ios oder gezielt für einzelne Dateisysteme)

Dedup und Spezielle Vdevs brauchen die gleiche Redundanz wie der restliche Pool. Benutzt man eine einzelne Platte (SSD/NVMe) und fällt diese aus, so ist der Pool verloren. Unterstützt werden daher neben einzelnen Platten n-way Mirrors. Bei mehreren Mirrors findet eine Lastverteilung statt. Raid-Zn wird nicht unterstützt.

Dedup- und spezielle vdevs kann man aus einem Pool auch wieder entfernen. Das klappt aber nur, wenn alle vdevs im Pool die gleiche ashift Einstellung haben, z.B. ashift=12 für 4k Platten.

Im aktuellen Illumos gibt es noch das Problem, dass bei einem Pool aus ashift=12 vdevs und einem special vdev mit anderem ashift, z.b. ashift=9 der Pool crasht wenn man versucht den zu entfernen. Im aktuellen napp-it dev stelle ich daher von ashift=auto auf ashift=12 als Default beim Erstellen oder Erweitern eines Pools um.

Ich habe das mal in der Illumos-dev Mailliste gemeldet und hoffe dass dieser Bug bald beseitigt wird.

 

[snipor]

Server hatte ich schon neu gestartet, leider ohne Erfolg. Beide Server sind über Gigabit Ports ans Netzwerk angeschlossen, kein Trunking etc. nur ein einzelner Port. Transfers von z.B. Windows Clients laufen von allen Pools auch problemlos mit annähernd der maximalen Port Geschwindigkeit (Gigabit) sowohl lesend als auch schreibend. Werde es mit einer lokalen Replikation noch einmal versuchen.

 

[Luckysh0t]

Gude,

kann man über die Shell dass Admin Kennwort von Nappit ändern (Solaris) ?
Hatte es über die GUI geändert - allerdings wohl zu lang bzw ungeeignete Zeichen verwendet, ich kann mich nicht mehr anmelden..