[Sammelthread] ZFS Stammtisch

Das Problem hatte ich auch mal, als ich versucht hatte einen Port der x540-T2 durchzureichen. Woran es lag, habe ich nicht weiter versucht herauszufinden. Nutze die jetzt halt über (zur Not exklusive) vSwitches.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das Problem hatte ich auch mal, als ich versucht hatte einen Port der x540-T2 durchzureichen. Woran es lag, habe ich nicht weiter versucht herauszufinden. Nutze die jetzt halt über (zur Not exklusive) vSwitches.

Gut, oder auch nicht...jedenfalls bin ich nicht der einzige mit dem Problem. Wäre aber interessant zu erfahren wieso omniOS mit dem Passthrough nicht zurechtkommt. Jedoch müsste man erst einmal ermitteln ob es an VMware oder OmniOS liegt, oder sogar systemspezifisch ist (Hardware). Könnte es sein, dass zu viele PCI Geräte im Passthrough sind, oder aus irgendwelchen Gründen die PCIe-Geräte in einer anderen Steckplatz-Reihenfolge auf dem Board sein müssen?
 
Für das Funktionieren von Pass-through ist nur die Hardware und ESXi zuständig.
Die VM bekommt das gar nicht mit. Wenn alles klappt, nutzt die die Karte so wie wenn das OS direkt auf Hardware installiert wäre.

Die X540-T2 ist aber ein einziges PCIe device.
Das kann man wenn dann nur komplett mit beiden Ports durchreichen.
 
Gelegentlich muss man sich doch über den sog. "Sachverstand" in renommierten Medien wundern. So schreibt Peter Siering von der c't in der aktuellen Ausgabe 8 im Artikel "Für alle Fälle, Software für den optimalen Server" auf Seite 94 Folgendes, Zitat:

"Kritisch sollte ein Server-Betreiber darauf blicken, was er einsetzt: Eine NAS-Distribution mit ZFS-Dateisystem mag aus technischer Sicht spannend sein, aber die verliert schnell Ihren Reiz, wenn aufgrund von Plattenausfällen die Daten am seidenen Faden hängen. Nicht jeder hat dann noch die Ruhe, detailliert in der Dokumentation nachzulesen, was zu tun ist. Für flatternde Nerven hat bewährte Technik, wie etwa die RAID-Funktion im Linux-Kernel, die tausendfach erklärt wird, etwas von Baldrian - auf die greifen auch die meisten NAS-Systeme zurück"

Das kommt rüber, als sei ZFS Software im Alpha-Stadium. Also gerade der Umgang mit RAID ist doch eines der Features von ZFS im Vergleich zu... ja was meint er eigentlich mit RAID-Funkton im Linux-Kernel? BTRFS doch wohl nicht, oder? :)
 
alte rausziehen, neue reinstecken und autorebuild ist halt einfacher (bzw Hotspare) :)
 
Verkehrte rausziehen und dann dumm dastehen ist aber auch ganz einfach ;)
 
verstehe ich jetzt was falsch
"alte rausziehen, neue reinstecken und autorebuild ist halt einfacher (bzw Hotspare)"

so gehts doch bei ZFS sofern die Platten anhand des Controller Ports verwaltet werden.
Wenn die Platten per WWN verwaltet werden weil damit die Platten-ID unabhängig vom Controller oder Server gleich bleibt, nimmt man Hotspare bzw disk replace "alte Platte" "neue Platte". Insgesamt alles sehr entspannt da selbst ein Teil-Rebuild (Stromausfall beim Rebuld, falsche Platte gezogen etc) einen ZFS Pool nicht beschädigt. Selbst ein weiterer Lesefehler beim Rebuild führt in nahezu allen Fällen nicht zu einem defekten Raid sondern lediglich zu einer defekten Datei da ZFS eben nicht nur das Raid sieht sondern auch den Inhalt verifiziert.

Zur c't Aussage fällt einem sonst nichts ein ausser dass der Autor vermutlich noch nie selbst ZFS Raid benutzt hat oder die bei ZFS doch sehr einfachen Abläufe nicht verstanden hat bzw. die gewohnten Abläufe nicht gefunden hat.
 
Jau, so klingt das auch für mich, insbesondere kennt er wohl dein napp-it nicht, die Schwimmbuxx.
 
Selbst auf der Konsole ist Raid Management unter ZFS eine Offenbarung
zpool status: zeigt einem das Raid und dessen Status
zpool replace alt neu: ersetzt eine defekte Platte

Ansonsten ist ZFS fast unkaputtbar.
Beliebige Platten im laufenden Betrieb an und abstecken: ZFS Raid überlebt das fast immer.
allenfalls könnte man anschliessend ein zpool clear zum Löschen der Fehler eingeben
Selbst unrecoverable read errors im degraded state führen meist nicht zu einem Verlust
des Raid sondern nur zum Verlust einer Datei.

Ein normales Raid-5/6 ist dagegen danach fast immer in einem kritischen Zustand egal ob Hardware oder Software Raid.
 
Zuletzt bearbeitet:
war doch nix gegen ZFS sondern nur für die Hardware Raid Controller Fraktion (evtl Begründung genannten Artikels)

... dass ihr immer alles gleich als Angriff versteht und den " :) " überseht
 
Jede Technik hat Unterschiede und Vor- und Nachteile.
Die Verfahren zum Ersetzen von Platten sind aber bei Softwareraid, Hardwareraid, Raid 5/6 und Raid-Z praktisch gleich.

Die zitierte c't Aussage stellt dagegen alles auf den Kopf.
Wenn man flatternde Nerven bei einem Plattenausfall hat, so hat man viel eher bei Raid- 5/6 Grund dazu als bei ZFS. Letzlich ist die Kernaussage, haben wir immer schon so gemacht, ist bewährt, kein Grund was zu ändern. Zudem machen das die meisten NAS Anbieter immer noch so.

Wenn das aber das Maß wäre, hätten Autos immer noch Blattfedern, kein Airbag, ABS oder ESP und würden auf schlechten Straßen höchstens 90 km/h fahren und es gäbe dennoch viel mehr Unfälle und Verletzte als heute.
 
Zuletzt bearbeitet:
Tja, die c't nähert sich langsam aber stetig dem Computerbildniveau an - vor 15 Jahren war das noch 'ne echte Fachzeitschrift!
 
... das Einstellungskriterium "langhaariger Bombenleger" ist ja auch schon fast 20 Jahre aus der Mode :)

früher hatte man als Personaler noch ne Schreibtischlampe und wenn er sich die Augen zuhielt beim Einschalten, dann war er nen Schritt weiter
 
Zuletzt bearbeitet:
Du solltest es hinkriegen, indem Du OmniOS eine zusätzliche, grössere virtuelle Platte gibst und mit dieser dann aus dem rpool einen Mirror machst.

Oracle Solaris 11 Express: Mirroring Your ZFS Root Pool und dabei "zpool set autoexpand=on rpool" setzt.

Danach hängst Du die alte virtuelle Disk im ESXi ab und testest ob die neue bootet, Wenn ja (rpool sollte jetzt wg. einer fehlenden Platte DEGRADED sein), solltest Du mit "zpool detach rpool <alte Platte>" einen sauberen und grösseren rpool haben.

Hat prima geklappt, vielen Dank nochmal für Deinen Tip. Folgenden Text habe ich dazu auch noch gefunden: ZFS - How to increase rpool in Solaris - UnixArena
 
Info

OmniOS 151018 stable ist verfügbar
größter Vorteil: erheblich verbessertes SMB, http://napp-it.org/doc/downloads/performance_smb2.pdf
ReleaseNotes/r151018

Ich bin gerade dabei,vorkonfigurierte Images (napp-it ToGo) vorzubereiten,
zu Beginn für die neuen SuperMicro Boards X11-SS. Auf denen kann man OmniOS nicht von USB installieren.
Die ready to use Images werden dann per CloneZilla geklont. Damit kann man dann auch Backup oder Disaster Recovery machen.
http://www.napp-it.org/doc/downloads/napp-it.pdf
 
Zuletzt bearbeitet:
@zos
gibt auch ne neue Serviio Version.1.6.1

Java8 ist in OmniOS immer noch net von Haus aus mit dabei oder?
 
Zuletzt bearbeitet:
Hi,

mein ZFS Pool wurde damals mit FreeNAS 9.3x erstellt (ZFS v28) und läuft soweit wunderbar.
Anhand einer Serverumstellung wollte ich den Pool nun direkt in Proxmox 4.x Debian Jessi einbinden.

Leider klappt dies nicht wie vermutet ;/
Im FreeNAS mit "zpool export name" wunderbar ausgeklinkt,
aber im Proxmox mit "zpool import name" oder "zpool import -D" bekomme ich immer "no pools available to import" ;/

Per "fdisk -l" und "fdisk /dev/sda usw..." sehe ich alle Platten wie auch mit ZFS Filesystem.

Ich denke die ZFS Version sollte kompatibel sein von Proxmox und FreeNAS ?!

Hoffe es kann mir jemand einen guten Tip geben um das Problem zu Lösen ;)

Danke & Lg ice
 
Zuletzt bearbeitet:
Also wenn man an der Zeittzone was ändert bricht die Installation jedesmal ab. Kann das wer bestätigen?OmniOS 151018
 
Wie mache ich denn auf einer bestehenden 151016 Installation am einfachsten ein Upgrade?


Gesendet von iPhone mit Tapatalk
 
@zos
gibt auch ne neue Serviio Version.1.6.1

Java8 ist in OmniOS immer noch net von Haus aus mit dabei oder?

Das ist nur eine marginale Änderung am Installationsscript, da muss nur die Variable $serviiover gesetzt werden:
...
$serviiover="1.6.1";
...
Ich hab's aber schon geändert, Installation kannst Du wie gehabt mit "wget -O - http://www.wp10455695.server-he.de/serviio16 | perl" starten.

Also wenn man an der Zeittzone was ändert bricht die Installation jedesmal ab. Kann das wer bestätigen?OmniOS 151018

Hab's noch nicht getestet, deshalb weiß ich auch noch nicht, welche Java-Version im neuen OmniOS verwendet wird. In den Release-Notes steht dazu nichts, wenn Du aber bereits r151018 installiert hast, kannst Du diese Info z.B. in der Datei "/usr/java/release" finden. Die Zeitzone kannst Du nachträglich mit dem Kommando "tzselect" ändern, wenn ich mich recht erinnere.

Wie mache ich denn auf einer bestehenden 151016 Installation am einfachsten ein Upgrade?

Wie ein Upgrade durchgeführt wird, ist hier beschrieben.
 
Zuletzt bearbeitet:
Wieso ist der Server eigentlich im Netzwerk jetzt nur noch über die IP erreichbar nicht aber mehr über NetBios. Bei früheren OmniOS Versionen funktionierte noch beides

Hängt offenbar mit
netbios_enable=false
Zusammen. Aber wieso wurde das geändert?
Bei den alten OmniOS Versionen fehlte der Eintrag noch
 
Zuletzt bearbeitet:
Wieso ist der Server eigentlich im Netzwerk jetzt nur noch über die IP erreichbar nicht aber mehr über NetBios. Bei früheren OmniOS Versionen funktionierte noch beides

Hängt offenbar mit

Zusammen. Aber wieso wurde das geändert?
Bei den alten OmniOS Versionen fehlte der Eintrag noch

Im neuen Illumos/ OmniOS 151018 wurden weite Teile des Kernel-SMB Servers erneuert (Upstream von Gordon Ross, Nexenta). Das bingt jede Menge Änderungen, u.a. SMB2 aber auch sonstiges. Bei manchen Sachen muss OmniTi noch etwas Feinschliff walten lassen. Mit SMB Guestaccess scheint es auch noch einen Bug zu geben.

btw. Info:
Es gibt ja einen ktitischen Bug für die SMB Server SAMBA und Windows, siehe badlock.org
Der Solaris Kernel-SMB Server ist nicht betroffen.
 
Ich habe einfach jetzt mal
sharectl set -p netbios_enable=true smb
gemacht. Jetzt seh ich den Server auch wieder.
Den Eintrag komplett wegzulassen hat aber wohl den selben effekt, weil es ihn bei meinen damaligen OmniOS Installationen gar nicht gab
 
Zuletzt bearbeitet:
Danke für den Hinweis.
Deswegen gab es schon Irritationen.

Im aktuellen napp-it kann man übrigens alle SMB Einstellungen auch per Menü kontrollieren/ setzen
Menü Service > SMB > Properties
 
(Wie) Kann man eigentlich die blocksize bei den LU-Volumes von z.B. 512 auf 4K ändern? Egal was ich bei der Einstellung der iSCSI Freigabe einstelle, im Comstar/LU-Menü steht immer 512 bei der blocksize.
 
Nach aussen werden aus Kompatibilitätsgründen immer 512B gemeldet.
Beim Anlegen eines Zvol kann man die Blocksize aber einstellen und es wird dann auch so genutzt.
Menü: Comstar > Volumes > create Volume

Nachträglich ändern kann man das aber nicht.
Man könnte aber ein neues zvol anlegen und per zfs send die Daten umkopieren.
 
Ok danke. Wo kann ich denn sehen, welche Größe "intern" verwendet wird? Hatte 4K oder 8k angegeben und nur leider vergessen was... ;)
 
Ich poste mal hier:
Welche OS für ZFS kann man denn nehmen um das System gut via SNMP zu überwachen? Vor allem Speicherbelegung und nach Möglichkeit i/o. Setze derzeit XPenology ein und da geht halt leider wenig.
 
Ok danke. Wo kann ich denn sehen, welche Größe "intern" verwendet wird? Hatte 4K oder 8k angegeben und nur leider vergessen was... ;)

Versuchs mal mit dem Kommando

zdb

In der Ausgabe steht u.a. der ashift-Wert.

EDIT:
ashift=12 => 4k blksize
ashift=13 => 8k blksize
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh