[Sammelthread] ZFS Stammtisch

Interessant wäre mal zu wissen, was passiert, wenn sich die Nummerierung ändern und eine Platte dann doppelt drin ist. Also über sde und einen der ata-WDC Einträge. Fliegen dann im schlimmsten Fall beide Platten aus dem Verbund und das komplette Z1 ist degraded?
Oder ist zfs clever genug, die Ursache des Schiefstands zu erkennen und die Poolmitglieder automatisch anzupassen?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
4.) hätte für mich den Charme,dass ich einen Pool verschlüsseln könnte und einen nicht wegen besserer Performance. Ich habe nur einen Pentium, welcher zwar ECC, aber kein AES-NI kann

Du hast 4x6TB SAS (äquivalente neue Exos ~800€) aber nur nen schäbigen Pentium ohne AES-NI? 30€ für nen E3-1220 v3 o.ä. sind nicht drin?

Prioritäten, echt...
 
Das aktuelle OpenIndiana 2019.05 kann ZFS Encryption nach einem
pkg upgrade

Dann den Pool upgraden, damit er das Feature unterstützt
pkg upgrade pool

Dann ein Key-File anlegen (ex 31 x 1)
echo 1111111111111111111111111111111 > /key.txt

Dann ein verschlüsseltes Dateisystem z.B. enc auf dem pool erzeugen
zfs create -o encryption=0n keyformat=raw -o keylocation=file:///key.txt pool/enc


Wichtig:
rpool nicht verschlüsseln (Boatloader unterstützt das noch nicht)
Keymanagement Options sind im Vergleich zu Solaris noch begrenzt

Documentationen zu Open-ZFS encryption sind noch begrenzt
was ich gefunden habe: How-To: Using ZFS Encryption at Rest in OpenZFS (ZFS on Linux, ZFS on FreeBSD, ...) - Philipps Tech Blog

Da wird zwar Verschlüssellung unter ZoL 0.8 beschrieben, gilt aber für alle Open-ZFS Optionen



update
aktuelle napp-it 19.dev unterstützt ZFS Encryption (Passwort prompt)
 
Zuletzt bearbeitet:
Du hast 4x6TB SAS (äquivalente neue Exos ~800€) aber nur nen schäbigen Pentium ohne AES-NI? 30€ für nen E3-1220 v3 o.ä. sind nicht drin?

Prioritäten, echt...

Der schäbige Pentium hat mir den bis jetzt super ausgereicht. Ich habe den Server gebraucht gekauft, den enthaltenen Xeon verhökert, den schäbigen Pentium gekauft und das Restgeld genommen und bin damit mit meiner Familie schön Essen gegangen. Das sind meine Prioritäten. Bisher lief auf dem Server ein Ubuntu mit ZoL, welcher Ulraubsfotos, Kindervideos und die private MP3/Film Sammlung im Hausnetz bereit stellt. Die Platten sind völlig übertrieben, die habe ich aber so auch nicht gekauft für den Vollpreis. Ich habe auch noch einen Dell Poweredge R320 und einen R610 rumliegen, beide haben aber nur Gehäuse für 2,5 Zoll Platten... Ich könnte wahrscheinlich die Platten + passenden SASController und den Server verkaufen, in den R320 dann 2,5" Platten rein kaufen und hätte wieder Geld übrig. Gar nicht so schlecht... :bigok:
 
Ich habe den Server gebraucht gekauft, den enthaltenen Xeon verhökert, den schäbigen Pentium gekauft und das Restgeld genommen und bin damit mit meiner Familie schön Essen gegangen. Das sind meine Prioritäten.

Von vornherein kleiner kaufen, OK. Aber kaufen, dann Arbeitsaufwand reinstecken und Händler spielen, um einmal Essen zu gehen, ist dermaßen sinnlos. Die Nachteile merkst du gerade selber. Hat sich ja richtig gelohnt, das Essen.
 
Jungs, das ist Spielkram. Ich war nicht darauf angewiesen, eine CPU zu verhökern, um Essen zu gehen. Für mich ist das ein Hobby, nicht mehr und nicht weniger. Die richtigen Server habe ich auf Arbeit stehen. Ich fand es interessant, dass der Pentium ECC Support hat und für so eine Ultra-Low-Budegt CPU läuft das Teil erstaunlich gut. Ubuntu mit ZoL und Verschlüsselung macht das Ding immerhin ~60 MB Transfer im GB-LAN. Da kann man echt nicht meckern...
 
Habe hier einen HP ML10 v2 stehen und möchte OmniOS auf einem USB3 Stick installieren. Funktioniert auch nur der bootvorgang bricht mitten drin ab und er meldet dass das Gerät nicht mehr verfügbar ist.
Der Server hat vorne 2mal USB2 und hinten 2mal USB3. Habe den Stick vorne dran an den USB2 Ports.

Wenn ich im Bios den USB Controller komplett auf USB2.0 stelle funktioniert es, mit der Einstellung USB3.0 bricht er ab.

Ich möchte zumindest einen der hinteren USB3 Ports für eine Backup Festplatte benutzen und natürlich auch USB3.0 Geschwindigkeit haben, USB2.0 macht kein Sinn mehr bei Platten mit mehreren TB.
Weiß jemand woran es liegt oder was man machen kann OHNE neue Hardware dabei anzuschaffen? Intern an den Sata Ports ist kein Platz mehr für eine OS SSD.
 
Hat jemand von euch auch die Erfahrung gemacht, dass Raidz2-Pools bei aktuellem Xigmanas@FreeBSD12 deutlich langsamer sind als auf der gleichen Version @BSD11 ? Bei 128KB Recordsize
Und zwar fast 30-40% sequentiell; einfachst per DD.
Bei Mirror-Päärchen oder einem Stripe aus 2*Raidz1 a 3 Platten hab ich das nicht festgestellt.

Bei absolut gleicher Rechner-, Platten- und Poolkonfig (X10SL7, 32GB, E3-1275v3, SAS2308 mit 6*Deskstar Nas 6TB dran).
Auf der 11er-Version liefert zpool iostat 6* 130-140 MB/s, bei der 12er-Version knapp unter 100 MB/s je Platte.
(Mirrors erreichen ~200 MB/s je Platte sowohl bei BSD 11 als auch BSD 12, das Delta dürfte wohl die Parityberechnung ausmachen).

Gehe ich bei der 12er-Version auf recordsize=1MB bei Raidz2, ist das weg und ich erreiche auch die 11er-Werte.

Firmware auf für den SAS-HBA ist aktuell, aus der Ecke sollte nix sein.
 
Zuletzt bearbeitet:
Folgendes Problem:
Ich habe OmniOS und Nappit neuaufgespielt und meinen Pool importiert. Ein Benutzerkonto für den Zugriff mittels SMB musste ich von UID 101 auf 104 ändern da UID101 von Nappit automatisch mit dem user "guest" angelegt wird.

Habe bei bei den ACLs nun den alten Eintrag modify für uid101 gelöscht und meinen neuen uid104 angelegt. Der Zugriff funktioniert auch soweit, bis auf dass bei Owner nun überall uid101 also guest steht.

Weiterhin ist jetzt kein Zugriff auf die Snapshots mehr möglich von uid104 (mit root geht es). Klicke ich auf einen Ordner im entsprechenden Dataset sind entweder alle Einträge verschwunden oder sie sind noch da es kommt dann aber eine Fehlermeldung wenn man den Snapshot anzeigen lassen will mit der Meldung er würde nicht mehr existieren.

Gehe ich direkt auf die Freigabe und wähle "previous versions" aus, werden die Snapshots angezeigt aber beim öffnen kommt eine Fehlermeldung dass die Zugriffsrechte fehlen.
Wie bekomme ich das jetzt wieder hin dass ich über mein neues Konto an die Snapshots komme?
 
Prinzipiell gibt es zwei Wege

1. man legt die User mit der alten uid an
(guest löschen und mit höherer uid neu anlegen)
Bei einer Neuinstallation hat man aber wieder das Problem.

2. Man setzt die Rechte rekursiv neu
(Snaps bleiben aussen vor)

guest braucht man beim aktuellem OmniOS für den Gastzugriff.
 
Zuletzt bearbeitet:
Hallo Community,

ich möchte meinen bestehenden verschlüsselten ZFS Container (zfs-on-linux), um weiteren vorhanden HDD Space erweitern.

Hier das Konstrukt in Kürze:

ZFS Filesystem <-top
|
LUKS Encryption
|
Raw disks <- bottom

Hat das jemand schon gemacht und hätte eine Anleitung parat? Ich möchte einen Datenverlust vermeiden.
 
Zuletzt bearbeitet:
Ich würde ja die Chance nutzen und auf native ZFS encryption migrieren.

- Backup machen, wie immer
- neuen (verschlüsselten) Pool mit neuen Platten anlegen
- per zfs send/receive Altdaten auf neuen Pool migrieren
- alten Pool+LUKS zerstören
- alte Platten zu neuem Pool hinzufügen.
 
Wäre eine Idee, ist aber nicht umsetzbar. Ich habe nur eine virtuelle HDD auf einer VM zur Verfügung. Die Ressourcen wurden nun nachträglich angepasst und ich möchte eben meinen bereits erstellten ZFS Container erweitern.
 
Wie sieht der Pool aktuell aus und wie soll er zukünftig aussehen? Die Encryption kannst Du dabei außen vor lassen, das ist quasi transparent (Luks auf neuen Disks erstellen und erst dann diese verschlüsselten Volumes aufnehmen).

Edit: ach so, Du hast jetzt quasi nur mehr Platz zugewiesen bekommen? Keine Änderung an Anzahl (1)/Level usw.?
 
Zuletzt bearbeitet:
Verstehe nicht was da nicht gehn soll. Die virtuelle HDD kommt von ESX oder sowas? Warum nicht eine weitere anlegen, migireren und die alte dann freigeben?
Oder direkt neuen Gast auf neuer HDD anlegen, dann gleich mit aktuellstem ZoL?
 
Wie sieht der Pool aktuell aus und wie soll er zukünftig aussehen? Die Encryption kannst Du dabei außen vor lassen, das ist quasi transparent (Luks auf neuen Disks erstellen und erst dann diese verschlüsselten Volumes aufnehmen).

Edit: ach so, Du hast jetzt quasi nur mehr Platz zugewiesen bekommen? Keine Änderung an Anzahl (1)/Level usw.?

Ja, mir wurde weiterer HDD Space zugeordnet, keine zusätzliche HDD sondern einfach nur mehr GB. Ich habe da auch keine Adminrechte, um mir selber Ressourcen zuzuweisen (das wär ja schön^). Das ist ein externer Webserver (VPS).
 
Prinzipiell gibt es zwei Wege

1. man legt die User mit der alten uid an
(guest löschen und mit höherer uid neu anlegen)
Bei einer Neuinstallation hat man aber wieder das Problem.

2. Man setzt die Rechte rekursiv neu
(Snaps bleiben aussen vor)

guest braucht man beim aktuellem OmniOS für den Gastzugriff.

Also komm ich bei Möglichkeit 2 nicht mehr an die alten snaps ran über den neuen account?
Ist es nicht ein Risiko irgendwo wenn die Rechte dort noch für uid101/guest eingestellt sind? Also könnte der Guest Account nicht darauf zugreifen?

Ist denn damit zu rechnen dass uid102 auch in Zukunft bei nappit dann der erste freie selbst anlegbare user bleibt sodass man das Problem nicht irgendwann wieder erneut hat?
uid101 dürfte doch von all denen schon für eigene accounts vergeben worden sein die nappit schon länger nutzen.

Ich verstehe das jetzt so als dass es im Grund nur über Möglichkeit 1 geht wieder an die Snaps zu kommen.

Kann ich später eigentlich ein nicht verschlüsseltes Datatset zu einem verschlüsselten senden und dort dann auch all die alten Snapshots? Oder muss ich hier später manuell die Dateien rüberkopieren?

Es wäre dumm wenn ich dann extra 2mal "von vorne" anfangen müsste und überlege ob ich dann einfach warte bis ich eh auf verschlüsselte datasets umsteige.
 
Zuletzt bearbeitet:
Man kann auch einfach mit usermod die uid von guest ändern.
Synopsis - man pages section 1M: System Administration Commands

Ansonsten sind Snaps halt immer readonly,
man kommt aber als root immer an alles

Ein unverschlüsseltes Dateisystem kann man an ein verschlüsseltes Dateisystem nur dann schicken, wenn das Ziel Dateisystem unlocked ist. Es erbt dann dessen Key. Dateisystems mit Snaps kann man als rekursive Replikation senden. Das ändert aber die Dateien nicht.

Ein verschlüsseltes Dateisystem kann man in Illumos auch "raw" senden. Es wird dann verschlüsselt übertragen und gespeichert und läßt sich mit dem Originalkey entschlüsseln.

Im Moment ist Illumos Open-ZFS Verschlüssellung nur im aktuellen OpenIndiana. Es wird gerade für OmniOS bloody getestet. Ich nehme stark an, dass es dann in OmniOS 151030 (Mai 2019) nachträglich kommt. Ich und viele andere warten da ganz dringend darauf. Die DSGVO fordert Datensicherheit nach Stand der Technik und das kann nur Verschlüssellung der Daten und des Backups bedeuten.


Zu ZFS Verschlüssellung in OpenIndiana (aus openindiana-discuss)

There was a bug in loader that if encryption was enabled even if not on
the Root dataset but like you on one in the rpool then loader would
refuse to load rpool.

Rhis has been fixed since then. Booting from encrypted dataset is still
not supported by loader as of today.
 
Dass Snaps readonly sein weiß ich, ich verstehe aber nicht den Zusammenhang mit ACLs und Snaps. Werden diese bei den Snapshots mit gesichert/eingefroren ?

Also wenn ich die Rechte oder Besitzer eines Datei/Ordners ändere nachdem ich einem Snapshot gemacht habe, kommt jemand der früher Zugriff hatte noch an den Snap wenn zu dem Zeitpunkt der Erzeugung des Snaps er noch Zugriff drauf hatte? Wer oder was legt dann fest wer auf das zugreifen kann? Gibt es dann pro Snapshot ne eigene ACL?
Oder anders gefragt wenn ich einen "Rollback" mache sind damit auch alte ACLs und Besitzer von Dateien und Ordnern wieder auf dem damaligen stand?
Mir geht es darum dass der User selber an seine Snapshots kommt ohne "root zu sein.
uid von guest zu ändern wäre wohl eine Möglichkeit.

ACL und Owner auf den user mit der neuen uid zu ändern funktioniert soweit auch (wenn auch nicht über SMB da kommt "unable to lookup user names for display" wenn man den Besitzer ändern will, selbst als root, das liegt aber wohl eher an SMB1 und der Abschaltung in Windows, ich mein wenn man SMB1 aktiviert geht es noch) , bis halt auf die Snaps, die werden gar nicht angezeigt dann für den entsprechenden user oder er spuckt ne Fehlermeldung aus dass der Snapshot nicht existiert.
Der Name des users ist identisch, wollte nur notgedrungen von uid101 auf 104 umziehen und dachte das sei mit ACL Anpassung und Änderung des Owners getan.

Besteht denn kein Risiko wenn die guest uid eine ursprünglich uid eines users hatte dass dort jemand mit dem guest konto nun die Snapshots einsehen kann die noch mit der alten uid erstellt wurden?
 
Zuletzt bearbeitet:
ACL sind Datei-Eigenschaften und damit im Snap eingefroren. Die ACLs beziehen sich im Workgroup Modus auf die uid (Daraus wird die Windows security id/sid abgeleitet). Im Domänenmodus wird nur die Domänen sid benutzt. Die ist dann eindeutig.

Prinzipiell ist es aber so
Wenn der Gastzugriff für ein Dateisystem aktiviert ist, kommt jeder ohne Passwort an alle Dateien und Snaps.

Wenn der Gastzugriff deaktiviert ist, kann sich "guest" weder an Unix noch per SMB anmelden, kommt also an nichts
 
Okay folgende Idee da ich die Snaps nur 1Jahr lang speichere: Könnte ich das guest konto nach hinter schieben und vorerst meine alte uid wieder benutzen, parallel ein zweites Konto einrichten und in der ACL die Rechte für dieses Konto identisch mit denen für mein altes also uid101 setzen.

Damit wären neue snaps sowohl für uid101 als auch uid104 (neues konto) einsehbar. Und wenn nach einem Jahr der letzte Snapshot gelöscht ist der nur uid101 hat, könnte ich mit guest wieder nach uid101 umziehen da ich ja mein neues konto mit uid104 habe und die Rechte entsprechend auch in den Snaps vorhanden sind.

praktisch wäre wenn Dateien die ich dann über uid101 erstelle aber automatisch uid104 als Besitzer schon bekommen

Zusammengefasst:
guest uid101 nach uid110 verschieben
user1 uid101 zusätzlich user2 uid104 anlegen mit selben Rechten wie user1 und Besitzer aller Ordner und Dateien von uid101 auf uid104 ändern
nach einem Jahr user1 uid101 löschen und guest uid101 wieder erstellen
uid104 weiterbenutzen.
Damit wären uid104 Besitzer aller Dateien und Ordner und kann auch alle zurückliegenden Snaps einsehen da diese Zugriff von sowohl uid101 als auch uid104 erlauben.
 
Zuletzt bearbeitet:
@gea
gibts unter ZoL die Möglichkeit auf zvol snapshots direkt zuzugreifen (so wies auf datasets ja auch geht), ohne dass ich vorher einen clone machen muss?
 
@gea
gibts unter ZoL die Möglichkeit auf zvol snapshots direkt zuzugreifen (so wies auf datasets ja auch geht), ohne dass ich vorher einen clone machen muss?

Ein zvol ist ja ein Blockdevice das in irgendeinem Dateisystem z.B. ntfs, ext4 etc formatiert ist. Man muss das z.B. über iSCSI einem Client zur Verfügung stellen. Dieses zur Verfügung stellen wird auch unter ZoL nur von einem zvol möglich sein, nicht von einem Snap.

Ein clone oder eine Replikation von einem snap wird wohl nötig sein.

- - - Updated - - -

Info

Einzeln verschlüsselbare Dateisysteme mit unterschiedlichen Schlüsseln (native ZFS encryption) ist jetzt auch in OmniOS 151031 bloody. Ein Riesen Fortschritt für Open-ZFS da die DSGVO Datensicherheit nach Stand der Technik fordert.

Für personenbezogene Daten und noch mehr für Backups kann das nur Verschlüssellung bedeuten.
 
JFYI, mein obiges Problem mit Raidz2-Performance unter FreeBSD12 (und auch 13, ich meine 11.3 hat auch schon das Problem) und damit Xigmanas 12.xxxx konnte ich nach ein bisschen Recherche und Testen zumindest vorübergehend lösen:

vfs.zfs.zio.dva_throttle_enabled=0 in die loader.conf und der Pool läuft wieder mit voller Geschwindigkeit. Knapp 200 MB/s per Platte (Hgst Deskstar 6 TB) sequentiell in den äusseren Spuren. Sprich sequentielles Schreiben auf dem Raidz2 mit 6 HDD rennt nun wieder mit ~800 Mb/s statt 450. So gehört sich das.
 
Zuletzt bearbeitet:
Warum throttled man das denn überhaupt runter?
 
Bei einem meiner ZFS Pools bekomme ich folgenden Fehler:

Code:
  pool: ESXi
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: none requested
config:

        NAME                       STATE     READ WRITE CKSUM
        ESXi                       ONLINE       0     0     0
          raidz1-0                 ONLINE       0     0     0
            c0t55CD2E414D4E6645d0  ONLINE       0     0     0
            c0t55CD2E414D4E7A07d0  ONLINE       0     0     0
            c0t55CD2E414DED225Ed0  ONLINE       0     0     0
            c0t55CD2E414DED552Cd0  ONLINE       0     0     0
        logs
          c2t1d0                   ONLINE       0     0     0
        cache
          c2t3d0                   ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        ESXi/vm:<0x0>

Es handelt sich um meinen ESXi VM Pool. Probleme konnte ich ansonsten bislang nicht feststellen.
Was kann ich da tun? Was ist das File <0x0>
 
Das defekte File ist nicht meht vorhanden z.B. weil der Snaphot mit dem File gelöscht wurde.

Einfach sicherheitshalber nochmal einen Scrub laufen lassen und dann ein Pool > clear error (zpool clear poolname) vornehmen.
 
Einfach sicherheitshalber nochmal einen Scrub laufen lassen und dann ein Pool > clear error (zpool clear poolname) vornehmen.

Nach dem Scrub war das "Problem" bereits behoben. Ein zpool > clear errors war vermutlich nicht nötig, habe es sicherheitshalber trotzdem nochmal gestartet.
Sieht jetzt alles wieder gut aus. Vielen Dank für den Support.
 
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