[Sammelthread] ZFS Stammtisch

Ja da sind alle da:

Code:
all_disks_unassigned	-> 	'c2t0d0 →c3t50014EE0AE2D7B0Dd0 →c3t50014EE2B40FD35Fd0 →c3t50014EE058D7E1C1d0 →c3t50014EE058D7EAF4d0 →c3t50014EE058D29090d0 →c3t50014EE00382AB3Fd0'
Code:
all_dsk	-> 	'c2t0d0 →c3t50014EE0AE2D7B0Dd0 →c3t50014EE0AE282758d0 →c3t50014EE2B40FD35Fd0 →c3t50014EE058D7E1C1d0 →c3t50014EE058D7EAF4d0 →c3t50014EE058D29090d0 →c3t50014EE00382AB3Fd0 →c3t50014EE20959D788d0'

- - - Updated - - -

Kann man das Kommentar Info/Feld auch direkt in der Map anzeigen lassen, oder muss man immer auf den Slot klicken?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hy,

ich habe wiedermal ne Frage bezüglich ZFS.

Ich habe auf einer SMB Freigabe ein Verzeichniss das ich nicht mehr löschen kann (das Element befindet sich nicht merh an diesem ort...).
Gibt es eine Möglichkeit direkt über napp-it Dateien/Verzeichnisse zu löschen?

Wie immer Thx für Infos
 
Am einfachsten auf der Konsole über Midnight Commander (mc) oder remote per WinSCP.
Für WinSCP SSH aktivieren, optional mit root=allowed (Menü Services > SSH).

Falls es ein Rechte-Problem ist, kann man auch per napp-it die ACL recursiv resetten
 
Ich habe eine Frage zu einer Namenauflösung im Zusammenhang mit SMB unter OmniOS. Gestern habe ich ein OmniOS System 151014 auf 151018 hochgezogen. Es handelt sich um ein AllInOne System mit virtualisiertem OmniOS und einem virtualisierten Windows Server 2012R2 unter ESXi 5.5. Nach Upgrade läuft alles problemlos inkl. Domainenanbindung von OmniOS etc. Allerdings funktioniert die Namenauflösung der Maschine plötzlich nicht mehr:

bisher wurden shares z.B. durch smb://OmniOS/Freigabe durch die Clients gemountet. Dies geht nun nicht mehr. Nun muss ich smb://<IP-Adresse>/Freigabe verwenden. Der Servername OmniOS wird nicht mehr aufgelöst, bei 151014 ging es aber.

Irgendwelche Tipps für mich?
 
Es gibt zwei Aspekte:

1. Der Server soll unter Netzwerkumgebung erscheinen
Dazu muss man netbios einschalten (napp-it Menu Services > SMB > Properties: netbios_enable=true)
Es muss zusätzlich ein Master Browser Dienst vorhanden sein (eine Windows Maschine). Solaris macht das nicht.

2. Namensauflösung
Das geht über DNS. Da OmniOS in der Domäne ist und damit der AD als DNS eingetragen ist, sollte das eigentlich funktionieren, zumindest wenn DHCP aktiviert ist. Eventuell den AD DNS kontrollieren, und bei Bedarfl den Eintrag manuell setzen.
 
Zuletzt bearbeitet:
Hallo zusammen,

da ich vor ein paar Monaten schon mal wegen SNMP Überwachung angefragt habe und meine Recherchen bzw Tests ergaben haben, dass das so nicht wirklich funktioniert, habe ich mir einen anderen Weg gesucht. Da ich mein Homelab eh mit ICINGA2 überwache habe ich meine Napp-IT VM jetzt auch damit unter Kontrolle. Wie man das ganze am Besten einrichtet habe ich in meinem Blog zu Bits und Bytes gebracht. Vielleicht ist das ja für einen von euch interessant.

https://www.tektoria.de/napp-it-vm-mittels-icinga2-ueberwachen/

Verbesserungsvorschläge nehme ich gerne entgegen.
 
Es gibt zwei Aspekte:

1. Der Server soll unter Netzwerkumgebung erscheinen

2. Namensauflösung
Das geht über DNS. Da OmniOS in der Domäne ist und damit der AD als DNS eingetragen ist, sollte das eigentlich funktionieren, zumindest wenn DHCP aktiviert ist. Eventuell den AD DNS kontrollieren, und bei Bedarfl den Eintrag manuell setzen.

Punkt 1. hatte ich genauso gemacht.

Punkt 2: Ich habe nun den Eintrag beim AD DNS manuell gesetzt, jetzt klappt es. Keine Ahnung wieso das vorher überhaupt funktioniert hat, DHCP habe ich nicht im Einsatz.

Vielen Dank gea
 
Habe jetzt mal für einen DL380e einen HP H220 Adapter bestellt um diesen per Durchreichen an FreeNAS zu betreiben.
 
Am einfachsten auf der Konsole über Midnight Commander (mc) oder remote per WinSCP.
Für WinSCP SSH aktivieren, optional mit root=allowed (Menü Services > SSH).

Falls es ein Rechte-Problem ist, kann man auch per napp-it die ACL recursiv resetten

Danke mit WinSCP hats natürlich funktioniert.

Auf die Idee hätte ich auch selbst kommen können :)
 
Buginfo: napp-it PoE encrypted pools
Es gibt einen Bug der dazu führen kann, dass ein verschlüsselter Pool nach einem Restart nicht mehr importiert werden kann.
Bitte
 
@gea: Hab jetzt mal die Änderung der 16.07 bzgl. des ersten Logins bei Replikation getestet -> funktioniert nun super. Danke.

Ich habe gerade auf einem Quellserver zwei Platten getauscht und alles aus dem Backup zurück-repliziert. Soweit so gut. Gibt es danach eine Chance den vorhandenen Replikations-Job auf dem Backup-Server weiter zu nutzen (inkl. des bereits vorhandenen ZFS-Dateisystems? Habe das aktuell so gemacht:

Backup zurück -> Quelle (knapp 7 TB)
Auf Backup Server Job und ZFS gelöscht
Quelle -> Backup neuen Job mit neuem ZFS (wieder 7TB)

Da ich nur 1GBit Netzwerk habe, dauert das immer eine ganze Weile. Lässt sich das besser lösen?
 
Die napp-it Storage Replikation läuft ja folgendermaßen:

- Nach einem Replikationslauf gibt es auf dem Quell- und Zielserver das gleiche Dateisystem
Da auf dem Quellsystem gearbeitet wird, sind beide üblicherweise nicht identisch

- Das Zieldateisystem ist readonly. Das ist kein Muss bei einer ZFS Replikation, hilft aber Fehler zu vermeiden

- Es gibt auf beiden Seiten einen Basissnapshot mit gleicher Replikationsnummer.
Dieser Snapshot ist der Datenstand nach der letzten Replikation. Dieser Datenstand ist auf beiden Seiten exakt identisch.

- Beim nöchsten Replikationslauf wird das Zieldateisystem auf diesen Snap zurückgesetzt und die Änderungen zu diesem Stand über einen neuen Quellsnap übertragen. Auf beiden Seiten gibt es dann einen neuen identischen Basissnap.


Um bei einer Replikation Quell- und Zielsystem zu tauschen muss man
- Die bisherige Replikation stoppen
- Das bisherige Zielsystem das ja das neue Quell Dateisystem werden soll auf rw schalten (disable readonly)
- Auf dem Backupsystem eine Replikation mit passendem Quell und Ziel ZFS anlegen

Der Schlüssel liegt lediglich darin, dass die neue Replikation die gleiche Job-ID erhalten muss wie die bisherige. Das kann man beim Anlegen des Jobs eingeben.
 
Kleine Frage ich möchte nächste Woche endlich mal mein ZFS Home Server die Software aktualisieren:

Aktuell bei mir im Einsatz Napp-It 0.92d

Aktuellste Version jetzt => 16.04f

Kann ich hier Napp-It einfach Upgrade oder was ist die optimale Vorgehensweise?

Aktuell bei mir im Einsatz OmniOS r151008

Aktuellste Version jetzt => LTS r151014 bzw. Stable 151018

Ist die LTS oder Stable zu bevorzugen, oder gibt es keine Großen Unterschiede, ist SMB 2.1 und Co. jetzt eigentlich vorhanden? Meine Version derzeit müsste aus dem normalen Stable build stammen. Irgendwas beim Upgrade beachten, oder zu empfehlen? Danke.
 
SMB 2.1 ist ab 151017 dabei

Vorgehensweise:
1. OmniOS updaten
- altes Repository abmelden
- 151018 Repository anmelden
- kontrollieren ob weniger als 30 BE/bootfähige Snaps vorhanden sind
https://omnios.omniti.com/wiki.php/Upgrade_to_r151014

dann mit pkg update updaten und ins neue System/BE booten


2. napp-it updaten
- geht in zwei Schritten, erst auf 16.01f dann auf 16.04f

Empfehlenswert ist ein vorheriges Backup der napp-it Einstellungen
(Job > napp-it backup) - nur für alle Fälle, ein Reinstall ginge dann auch in ein paar Minuten.
 
Zuletzt bearbeitet:
Wie dramatisch wäre es ein Raid-z2 mit 8 Platten (statt der optimalen 10) zu bauen. Das System dient nur zur Dateiablage für 2 Benutzer. Klar wird es gehen, aber wie massiv sind die Einschränkungen die man sich damit einhandelt? Ich würde halt gern das Asrock C236 WSI mit 8 x SATA benutzen können und ja, es muss Mini-ITX sein...
 
ZFS schreibt Daten in variablen Blöcken von 1M, 512k, 256k, 128k, 64k, 32k,.. (je nach Einstellung, default 128k).
Wenn die Anzahl der Datenplatten keine Zweierpotenz ist, dann gibt es bei jedem Datenblock einen kleinen "Verschnitt". Wenn man z.B. 128k auf 6 Datenplatten verteilen muss, kommt auf jede Platte 21,3k. Bei einer 4k Platte verbraucht das aber 24k als nächste Möglichkeit da jeder Block immer mindestens 4k groß sein muss. Der Verschnitt liegt also ca bei 15%.

Wären es 8 Datenplatten, dann würden bei 128k auf jede Platte 16k kommen. Das sind vier 4k Blöcke, also kein Verschnitt
Die Nutzkapazität ist also etwas kleiner.
 
Das ist ja runtergebrochen fast eine Platte Verschnitt. :fire: Also werde ich wohl doch mit 10 Platte arbeiten müssen. Es liegen auf dem NAS halt meist große Dateien aber auch tausende im Bereich 100kB bis 2-3 MB

Wenn ich drüber nachdenke ist der Verschnitt aber ein grundsätzliches Problem und unabhängig von den geschriebenen Dateigrößen - Richtig?
 
Zuletzt bearbeitet:
Ne, also wenn ich das oben jetzt mal übertrage, hättest du mit 10 Platten bei 128k auf jeder Platte 12,8k. Das sind bei 4k wenigstens 16k und daher auch mit Verschnitt. Wie geschrieben, keinen Verschnitt bei 8 Platten. 10 ist ja auch keine Zweierpotenz ;)
 
@morph027: Er redet von RAIDZ2 also hat er Recht denn es handelt sich um 8 Datenplatten und 2 für Parity... 8+2=10

Also kein Verschnitt bei 10 Platten.
 
Das ganze ist aber überhaupt nicht kalkulierbar, wenn man lz4 Kompression auf dem vDev eingestellt hat.
 
Compress ist genau genommen eine Eigenschaft eines Dateisystems, nicht eines vdevs.
Ist aber nicht entscheidend, da die Komprimierung vor dem Speichern stattfindet.

Für den "Verschnitt" ist die Platten Sektorgröße (512B oder 4k) und die ZFS Blocksize entscheidend.
Bei einer größeren Blocksize wird der Verschnitt auch geringer, kann aber andere teils negative Auswirkungen haben - je nach Anwendungsfall. Bei einem reinen Mediaserver eventuell sogar positive bei einem Mailserver oder VM Multiuser Storage eher negative.

Durch die variable Blocksize für die Daten die über das n x Blocksize gehen ist es aber insbesondere mit Compress tatsächlich schwer kalkulierbar.
 
Zuletzt bearbeitet:
SMB 2.1 ist ab 151017 dabei

Vorgehensweise:
1. OmniOS updaten
- altes Repository abmelden
- 151018 Repository anmelden
- kontrollieren ob weniger als 30 BE/bootfähige Snaps vorhanden sind
https://omnios.omniti.com/wiki.php/Upgrade_to_r151014

dann mit pkg update updaten und ins neue System/BE booten


2. napp-it updaten
- geht in zwei Schritten, erst auf 16.01f dann auf 16.04f

Empfehlenswert ist ein vorheriges Backup der napp-it Einstellungen
(Job > napp-it backup) - nur für alle Fälle, ein Reinstall ginge dann auch in ein paar Minuten.

Vielen Dank, werde ich so umsetzen, auch optisch hat sich ja napp-it verändert, gefällt mir.
 
..auch optisch hat sich ja napp-it verändert, gefällt mir.

Das ist ein ganz schwieriges Thema.
Ein "echter" Solaris Storage Admin verabscheut eine GUI wie napp-it. Admins die nicht 24/7 nur Solarish und ZFS betreuen freuen sich über eine GUI, da gehöre ich selber dazu. Der Mainstream ist aber momentan schicke App orientierte Oberflächen und viele Extras wie bei Synology & Co.

Da kann und will ich aber nicht hin. Ich habe napp-it ursprünglich nur zur Wartung meiner Storage Installationen gemacht. Zwischenzeitlich ist das auch bei vielen kommerziellen Solarish Nutzern, auch bei richtig großen Installationen im Einsatz. Napp-it muss daher auch in der GUI besser werden. Ich werde es aber weiter so einfach wie möglich halten. Nur dadurch kann ich (und andere) neue Features in kurzer Zeit einbauen auch wenn ich immer wieder höre - gefällt mir (nicht). Alle 2-3 Jahre eine neue Release und dazwischen nur Bugfixing wäre für mich aber undenkbar da Oracle oder Illumos auch konstant neues einbaut. Schicke Oberflächen hemmen - sofern man keine entsprechenden Entwickler-Resourcen hat.

Ich mag aber auch generell simple technology.
Ich bin da echt gebrannt durch die total disfunktionale Licht/Heizung/Zuko/Klima/Beamer/Multimedia Technik an unserer Einrichtung. 100 Jahre technische Entwicklung haben funktionierende Lichtschalter, Heizungsventile, Türschlösser und mechanische Schalter hervorgebracht. Das was viele als modern und zeitgemäß betrachten ist das was vielleicht in 100 Jahren gut funktionieren wird aber bis dahin nichts als Ärger erzeugt.

Keep it simple!
 
Zuletzt bearbeitet:
Das ist ein ganz schwieriges Thema.
Ein "echter" Solaris Storage Admin verabscheut eine GUI wie napp-it.
Genauso ist es, un genau diese Sichtweise ist es auch, die immer wieder verhindert, daß Linux oder FreeBSD (und sonstige Unixoiden Systeme) eine breite Nutzerschicht bekommen. Bei Linux hat man mit Ubuntu und ähnlichen Distris mitklerweiiel Distributionen rausgebracht, bei denen der "gemeine Anwender" nach Möglichkeit nichts mehr mit der Shell zu tun bekommt. Mit PC-BSD gibt es in der FreeBSD Ecke einen vergleichbaren Ansatz.

Andererseits geht man bei Microsoft mitlerweile wieder "Back to the Roots" - Powershell und Textmode-Only Installation der aktuelleren Serverversionen.

Die Shell hat einen Fehler : "Tippfehler können teuer werden"
GUIs minimieren genau diese Fehleranfälligkeit. Natürlich kann man auch in einer GUI irgendwo einen Haken falsch setzen.

Mach weiter so, Danke!!
 
Ich hätte noch eine Frage an (wahrscheinlich) @gea
Erkennt Omnios aktuell den "Syba SI-PEX40064 Adapter" oder ist dazu Frickelei nötig? Chipsatz auf dem Ding ist ein Marvell 88SE9215...
 
Ich hätte noch eine Frage an (wahrscheinlich) @gea
Erkennt Omnios aktuell den "Syba SI-PEX40064 Adapter" oder ist dazu Frickelei nötig? Chipsatz auf dem Ding ist ein Marvell 88SE9215...

Ob er erkannt wird - weiss ich nicht. Ich wäre skeptisch.
Frickelei hilft dann gar nichts ausser man will selber einen Treiber entwickeln.

Entscheidender ist aber: Ist es ein gute Wahl für Solarish und da ist die Anwort ein entschiedenes nein.
Man sollte unter Solarish entweder Intel Sata/AHCI oder LSI HBAs wählen - sonst nichts -.

Also z.B. Dell H200, IBM 1015 als OEM oder halt Original LSI/Avago
 
vielleicht hilft da der Thread: https://forums.servethehome.com/ind...and-hba-complete-listing-plus-oem-models.599/

ist nicht vollständig, aber sollte schon mal helfen

korregier mich bitte, aber 2008/2308/3008 mit IT Firmware sollten doch gehen (ohne Cache/Raid als HBA) wobei die 2008 nativ laufen sollten (mit IT FW als HBA)

interessant wäre aber zu wissen ob z.B. der hier nativ läuft : https://www.amazon.de/dp/B00AZ9T3OU/ (zu meiner Schande, hab nie napp-it benutzt ^^ ) .. der rennt aber bei meinen Home Teilen gut (mit 2,5" hdds)
 
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