[Sammelthread] ZFS Stammtisch

Wenn ntpd läuft, geht ntpdate nicht. ntpdate ist ein "one-shot" Tool, um einmal die Zeit zu setzen. ntpd läuft permanent und setzt nicht die Zeit - bzw. je nach Option einmal beim Start - sondern beschleunigt oder verlangsamt die Systemuhr, bis sie synchron läuft.

Wie lange lief denn der ntpd, als du ntpq benutzt hast? Der ntpd braucht schon einige Zeit, um warmzulaufen. Wenn die Systemuhr sehr grob abweicht, benutze die Option, die beim Start einmal die Uhr setzt. Bei meinem ist das

Code:
       -g, --panicgate
              Allow the first adjustment to be Big.

              Normally, ntpd exits with a message to the  system  log  if  the
              offset  exceeds the panic threshold, which is 1000 s by default.
              This option allows the time to  be  set  to  any  value  without
              restriction;  however, this can happen only once. If the thresh-
              old is exceeded after that, ntpd will exit with a message to the
              system  log. This option can be used with the -q and -x options.
              See the tinker configuration file directive for other options.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn ntpd läuft, geht ntpdate nicht.

Das muss man erst mal wissen. :wall:

ntpdate ist ein "one-shot" Tool, um einmal die Zeit zu setzen. ntpd läuft permanent und setzt nicht die Zeit - bzw. je nach Option einmal beim Start - sondern beschleunigt oder verlangsamt die Systemuhr, bis sie synchron läuft.

Wenn ich dich jetzt richtig verstehe nutzt man ntpdate zum einmaligen setzen der Zeit oder/und per cron gesteuert zu bestimmten Zeiten.
Der Dienst ntpd synchronisiert - je nach Option - einmalig oder so lange bis die Systemuhr synchron läuft - also überprüft regelmässig mit den eingestellten Zeitservern seine Systemzeit und passt Diese 'langsam' an.
Code:
root@aio:~# svcprop ntp
config/always_allow_large_step boolean true
config/debuglevel integer 0
config/logfile astring /var/ntp/ntp.log
config/mdnsregister boolean false
config/no_auth_required boolean false
config/slew_always boolean false
config/value_authorization astring solaris.smf.value.ntp
config/verbose_logging boolean false
config/wait_for_sync boolean false
general/enabled boolean false
general/action_authorization astring solaris.smf.manage.ntp
general/entity_stability astring Unstable
general/single_instance boolean true
general/value_authorization astring solaris.smf.value.ntp
network/entities fmri svc:/network/service
network/grouping astring require_any
network/restart_on astring error
network/type astring service
filesystem/entities fmri svc:/system/filesystem/minimal
filesystem/grouping astring require_all
filesystem/restart_on astring error
filesystem/type astring service
manifestfiles/lib_svc_manifest_network_ntp_xml astring /lib/svc/manifest/network/ntp.xml
start/exec astring /lib/svc/method/ntp\ %m
start/group astring root
start/privileges astring basic,!file_link_any,!proc_info,!proc_session,net_privaddr,proc_lock_memory,proc_priocntl,sys_time
start/timeout_seconds count 600
start/type astring method
start/use_profile boolean false
start/user astring root
restart/exec astring /lib/svc/method/ntp\ %m
restart/group astring root
restart/privileges astring basic,!file_link_any,!proc_info,!proc_session,net_privaddr,proc_lock_memory,proc_priocntl,sys_time
restart/timeout_seconds count 1800
restart/type astring method
restart/use_profile boolean false
restart/user astring root
stop/exec astring :kill
stop/timeout_seconds count 60
stop/type astring method
tm_common_name/C ustring Network\ Time\ Protocol\ \(NTP\)\ Version\ 4
tm_man_ntpd/manpath astring :default
tm_man_ntpd/section astring 1M
tm_man_ntpd/title astring ntpd
tm_man_ntp_conf/manpath astring :default
tm_man_ntp_conf/section astring 4
tm_man_ntp_conf/title astring ntp.conf
tm_man_ntpq/manpath astring :default
tm_man_ntpq/section astring 1M
tm_man_ntpq/title astring ntpq
restarter/logfile astring /var/svc/log/network-ntp:default.log
restarter/contract count 117
restarter/start_pid count 8497
restarter/start_method_timestamp time 1392580578.472201000
restarter/start_method_waitstatus integer 0
restarter/auxiliary_state astring dependencies_satisfied
restarter/next_state astring none
restarter/state astring online
restarter/state_timestamp time 1392580578.474348000
restarter_actions/auxiliary_tty boolean true
restarter_actions/auxiliary_fmri astring svc:/network/ssh:default
root@aio:~#
Welche der vielen Optionen stellt jetzt "ntpd läuft permanent und setzt nicht die Zeit - bzw. je nach Option einmal beim Start - sondern beschleunigt oder verlangsamt die Systemuhr, bis sie synchron läuft" ein? Oder bin ich wieder falsch?

Wie lange lief denn der ntpd, als du ntpq benutzt hast? Der ntpd braucht schon einige Zeit, um warmzulaufen. Wenn die Systemuhr sehr grob abweicht, benutze die Option, die beim Start einmal die Uhr setzt. Bei meinem ist das
Noch nicht lange, da ich den Server noch am Konfigurieren bin.
Code:
       -g, --panicgate
              Allow the first adjustment to be Big.

              Normally, ntpd exits with a message to the  system  log  if  the
              offset  exceeds the panic threshold, which is 1000 s by default.
              This option allows the time to  be  set  to  any  value  without
              restriction;  however, this can happen only once. If the thresh-
              old is exceeded after that, ntpd will exit with a message to the
              system  log. This option can be used with the -q and -x options.
              See the tinker configuration file directive for other options.
Ich finde/weis es nicht, wie diese Option angegeben werden kann. :mad:
 
Wie gibt man eigentlich am sinnvollsten Sachen frei? Nested Shares gehen ja nicht, meine Idee ist folgende Datesets anzulegen:

User1
User1/Dokumente
User1/Bilder
User1/Backup
User1/Musik

User2.... usw.

Das Dataset User1 gebe ich frei (SMB/CIFS) und was dadrunter liegt mache ich SMB=off (wenn ich es auch freigeben würde wäre es ja ein nested Share)

Habe auch erst überleg nur das jeweils unterste Dateset freizugeben aber das ist unklug weil es ja bei mehreren Usern dann mehrere gleichnamige Datasets ("Dokumente" zb) gibt und das wiederum nicht geht

Ist sowas klug? Oder lieber User1, User2 als Dataset und Dokumente dann einfach als ganz normale Ordner machen?
 
Zuletzt bearbeitet:
Das Dataset User1 gebe ich frei (SMB/CIFS) und was dadrunter liegt mache ich SMB=off (wenn ich es auch freigeben würde wäre es ja ein nested Share)

Das Grundproblem sind nicht nested shares sondern nested filesystems. Da shares eine Eigenschaft des Dateisystems sind geht das dann auch nicht.

Ursache:
Dateisysteme können komplett unterschiedliche Eigenschaften haben (z.B. unterscheide Groß/Kleinschreibung oder nicht). Daher gehen (noch) keine CIFS shares in tieferliegende Dateisysteme. (Es wird daran gearbeitet)

Es geht also nur, jedes Dateisystem mit einer eigenen Freigabe versehen.

Alternative
Ein Dateisystem user1 anlegen und freigeben. Darunter liegen dann nur normale Ordner.
 
Wenn ich dich jetzt richtig verstehe nutzt man ntpdate zum einmaligen setzen der Zeit oder/und per cron gesteuert zu bestimmten Zeiten.
Richtig.

Der Dienst ntpd synchronisiert - je nach Option - einmalig oder so lange bis die Systemuhr synchron läuft - also überprüft regelmässig mit den eingestellten Zeitservern seine Systemzeit und passt Diese 'langsam' an.
Vorrangig synchronisiert er immer die Systemuhr. Die Option zum einmaligen Setzen (im Vergleich zum langsamen Anpassen) der Zeit dient dazu, dass er große Zeitunterschiede nicht über Tage oder Wochen hinweg durch Anpassen der Uhrengeschwindigkeit ausgleicht, sondern quasi auf einen Schlag eine halbwegs synchrone Ausgangsbasis schafft und dann synct. Dass es dafür extra eine Option gibt, hängt damit zusammen, dass es auch Anwendungen gibt, wo eine grob abweichende Uhrzeit beim Start auf ein sicherheitsrelevantes Problem hindeuten kann und lieber der Admin informiert wird als still und leise die Uhrzeit anzupassen.

Welche der vielen Optionen stellt jetzt "ntpd läuft permanent und setzt nicht die Zeit - bzw. je nach Option einmal beim Start - sondern beschleunigt oder verlangsamt die Systemuhr, bis sie synchron läuft" ein? Oder bin ich wieder falsch?
Da muss wohl ein Solaris-Typ ran. Ich bin BSD-verwöhnt :>

Noch nicht lange, da ich den Server noch am Konfigurieren bin.

Ich finde/weis es nicht, wie diese Option angegeben werden kann. :mad:

"Emulieren" kannst du diese Option, indem du den ntpd stoppst, einmal ntpdate <ntpserver> aufrufst und dann den ntpd wieder startest. Ab da sollte ja die Zeit nicht mehr grob abweichen. Und beim ntpd ruhig etwas Geduld haben, das kann schon mal ein paar Minuten dauern. Dass er richtig läuft, erkennst du daran, dass das Stratum von 16 auf 2 oder 3 springt, je nachdem, welchen Server du nimmst.
 
Zuletzt bearbeitet:
Das Grundproblem sind nicht nested shares sondern nested filesystems. Da shares eine Eigenschaft des Dateisystems sind geht das dann auch nicht.

Ursache:
Dateisysteme können komplett unterschiedliche Eigenschaften haben (z.B. unterscheide Groß/Kleinschreibung oder nicht). Daher gehen (noch) keine CIFS shares in tieferliegende Dateisysteme. (Es wird daran gearbeitet)

Es geht also nur, jedes Dateisystem mit einer eigenen Freigabe versehen.

Alternative
Ein Dateisystem user1 anlegen und freigeben. Darunter liegen dann nur normale Ordner.

Bei mir geht es zumindest kann ich drauf zugreifen. Wie kann das denn sein?

Sprich das oberste Dataset freigeben und weitere subdatesets nicht freigegeben.
 
Der ntp Direnst ist normalerweise nicht aktiviert,
ntpdate 0.de.pool.ntp.org ist deshalb zunächst richtig

Ob der Server erreichbar ist und antwortet, kann man mit
ntpdate -d 0.de.pool.ntp.org herausfinden

Hinter einer Firewall muss man zum Setzen meist folgendes eingeben (use unprivileged Port):
ntpdate -u 0.de.pool.ntp.org


Automatisieren kann man dann z.B. mit "other job" oder cron


mehr
Synopsis - man pages section 1M: System Administration Commands

- - - Updated - - -

Bei mir geht es zumindest kann ich drauf zugreifen. Wie kann das denn sein?

Sprich das oberste Dataset freigeben und weitere subdatesets nicht freigegeben.

Ach Sieh da - man lernt nie aus.
Ich wusste zwar, dass daran gearbeitet wird, es ist mir aber entgangen dass es bereits enthalten ist-
dabei ist es egal ob das Sub-Dateisystem SMB aktiviert hat - über das Elterndateisystem kommt man rein.

Wenn SMB aktiviert ist, erscheint es eben zusätzlich direkt als eigenes Share.
 
Aber die Frage bleibt was hat man davon verschachtelte Datasets zu machen?

Mir fällt nur ein kann Snapshots feiner einstellen und dass ich die Freiheit hab später immer noch die Freigabe des obersten Datasets zu beenden und die Subdatasets dann einzeln freizugeben falls ich beispielsweise nicht die selben Rechte vergeben möchte
 
Aber die Frage bleibt was hat man davon verschachtelte Datasets zu machen?

Mir fällt nur ein kann Snapshots feiner einstellen und dass ich die Freiheit hab später immer noch die Freigabe des obersten Datasets zu beenden und die Subdatasets dann einzeln freizugeben falls ich beispielsweise nicht die selben Rechte vergeben möchte

dazu noch eigene Quotas, Reservierungen und Replikationen und all die anderen ZFS Eigenschaften -
ich würde aber auch eher nicht schachteln sondern flache Strukturen machen.
 
Vorrangig synchronisiert er immer die Systemuhr. Die Option zum einmaligen Setzen (im Vergleich zum langsamen Anpassen) der Zeit dient dazu, dass er große Zeitunterschiede nicht über Tage oder Wochen hinweg durch Anpassen der Uhrengeschwindigkeit ausgleicht, sondern quasi auf einen Schlag eine halbwegs synchrone Ausgangsbasis schafft und dann synct. Dass es dafür extra eine Option gibt, hängt damit zusammen, dass es auch Anwendungen gibt, wo eine grob abweichende Uhrzeit beim Start auf ein sicherheitsrelevantes Problem hindeuten kann und lieber der Admin informiert wird als still und leise die Uhrzeit anzupassen.

Na so sollte es ja IMHO sein.
Ich würde jetzt nur noch gerne diese Option
Code:
-g, --panicgate
setzen, damit beim Start der größte Zeitunterschied gleich bereinigt wird.
Wie kann ich diese Option fest setzen? Kann mir da jemand weiter helfen?

Da muss wohl ein Solaris-Typ ran. Ich bin BSD-verwöhnt :>
Na du glücklicher. Ich bin eher der MSFT versaute Typ.

"Emulieren" kannst du diese Option, indem du den ntpd stoppst, einmal ntpdate <ntpserver> aufrufst und dann den ntpd wieder startest. Ab da sollte ja die Zeit nicht mehr grob abweichen. Und beim ntpd ruhig etwas Geduld haben, das kann schon mal ein paar Minuten dauern. Dass er richtig läuft, erkennst du daran, dass das Stratum von 16 auf 2 oder 3 springt, je nachdem, welchen Server du nimmst.

Das werd ich mal testen.

Danke für deine Hilfe.

Welche Uhrzeit stellt ihr eigentlich so ein? Im BIOS, ESXi und Omnios?
UTC oder Europe/Berlin

Der ntp Direnst ist normalerweise nicht aktiviert,
ntpdate 0.de.pool.ntp.org ist deshalb zunächst richtig

Ob der Server erreichbar ist und antwortet, kann man mit
ntpdate -d 0.de.pool.ntp.org herausfinden

Hinter einer Firewall muss man zum Setzen meist folgendes eingeben (use unprivileged Port):
ntpdate -u 0.de.pool.ntp.org

Automatisieren kann man dann z.B. mit "other job" oder cron

So war ja auch mein ursprünglicher Plan, die Zeit mit other job zu aktualisieren.
Also dachte ich zuerst den Dienst ntp konfigurieren und starten - dass dann ntpdate nicht mehr funzt - wußte ich ja nicht.
 
Welche Uhrzeit stellt ihr eigentlich so ein? Im BIOS, ESXi und Omnios?
UTC oder Europe/Berlin

BIOS-Uhr ist egal. Im Betrieb zählt eh nur die Systemuhr, die je nach System die BIOS-Uhr entweder immer direkt oder beim Runterfahren synct. ESXi sollte einen NTP-Server konfiguriert haben, und wenn die VMs nicht über die VMTools synchronisiert werden, sollte darin auch nochmal ein NTP-Client laufen. Die ESXi-Uhr und die VM-Uhren sind unabhängig.

Die Zeitzone kannst du einstellen, wie du es brauchst (dann aber nicht die Uhr auf Ortszeit setzen während z.B. UTC eingestellt ist). Generell gilt: einfach die gewünschte Zeitzone im System einstellen und ntpd machen lassen. ntpd hat AFAIK kein Konzept von Zeitzonen. Da geht alles in UTC. Die BIOS-Uhr sollte eh immer in UTC laufen.
 
Wird bei OpenZFS eigentlich an einer Verschlüsselung gearbeitet? Also integriert ins Filesystem?
 
Nicht wirklich, geplant, aber soweit ich weiß arbeitet aktuell keiner wirklich dran. Ist nicht unbedingt ein Feature was irgendeiner der "Geldgeber" von OpenZFS wirklich interessiert. Ich bin mir sicher wenn man etwas Geld dafür auftreibt sich da in kurzer Zeit etwas tun könnte.
Projects - OpenZFS- Platform_agnostic_encryption_support

https://github.com/zfsonlinux/zfs/issues/494
Für ZFSonLinux gibt es einen die Alpha/Beta-Encryption noch aus Opensolaris mit Poolversion 30 in https://github.com/zfsrogue/zfs-crypto, daran wird auch aktuell noch gearbeitet.
Ist aber nicht wirklich gereift und sollte nur für Testzwecke verwendet werden. Vielleicht wird das mal die Grundlage für die OpenZFS-Crypto-flag, ist aber alles etwas problematisch da der Code auf dem das aufbaut wohl nie ganz offiziell released worden ist und Oracle den neuen Code ja nicht mehr heraus gibt.

Wenn du mit ZFS größere Datenmengen verschlüsseln willst solltest du zu Linux (luks/dmcrypt) oder FreeBSD(geli) greifen, unter Linux wirst du wohl die bessere Performance haben sofern du einen aktuellen Kernel verwendest. Die Closed-Source Crypto von Solaris 11 ist inperformanter Murks. Verschlüsselte lofi-devices unter Solaris sind eher etwas für kleinere Datenmengen und auch nicht wirklich performant, wenn es dir aber nur um ein paar Daten geht kann man das sicherlich nutzen. Ich verschlüssele aber immer grundsätzlich alle Systeme vollständig und mache keine Unterschiede zwischen unwichtigen und schützenswerten Daten, ist so wesentlich einfacher zu handeln.
 
Zuletzt bearbeitet:
Die Closed-Source Crypto von Solaris 11 ist inperformanter Murks.

Na, dafür ist sie eingebaut und man muss nicht noch ein LUKS o.ä. drumrumschachteln, das seinerseits Probleme machen kann, separat eingerichtet werden will, und das nunmal kein Teil von ZFS ist, wenns um Sachen wie autoexpand geht.
Klar, mir wäre veröffentlichter Code grade in dem Bereich auch lieber, aber mir fehlt momentan das Kleingeld, um diesen Saft-Laden (hübscher Wortfilter!) aufzukaufen und vom Erdboden verschwinden zu lassen. Bis das passiert wirds halt leider so bleiben...
 
Na, dafür ist sie eingebaut und man muss nicht noch ein LUKS o.ä. drumrumschachteln, das seinerseits Probleme machen kann, separat eingerichtet werden will, und das nunmal kein Teil von ZFS ist, wenns um Sachen wie autoexpand geht.

Wieso soll ein Mechanismus, der einfach 1:1 ein block device verschlüsselt, mehr Probleme machen als einer, der im Filesystem integriert ist? Und wo ist das Problem bei autoexpand? Du hast vorher ein block device mit x Blöcken und hinter ein eins mit x Blöcken, die dann verschlüsselt sind. Für ZFS sieht das doch kein Stück anders aus, und es verhält sich auch genauso.
 
Wieso soll ein Mechanismus, der einfach 1:1 ein block device verschlüsselt, mehr Probleme machen als einer, der im Filesystem integriert ist? Und wo ist das Problem bei autoexpand? Du hast vorher ein block device mit x Blöcken und hinter ein eins mit x Blöcken, die dann verschlüsselt sind. Für ZFS sieht das doch kein Stück anders aus, und es verhält sich auch genauso.


Ich find das dumm gelöst. Hatte auch mal GELI, aber das sitzt ja UNTERHALB von ZFS. Sprich selbst beim Scrub muss total unnötigerweise entschlüsselt werden, auch resilvering bremmst der ganze Spaß aus.

Technisch gesehen ist es wesentlich kleverer verschlüsselte Daten auf konsistenz zu überprüfen, so spart man sich die entschlüsselung.

Außerdem hätte ich bei einer eingebauten Verschlüsselung die Möglichkeit nicht alles zu verschlüsseln.
Der einzige Nachteil der Solaris Verschlüsselung ist doch der dass es nicht open source ist.

Wieso soll es unter Solaris "lahm" sein? Ich hatte dazu mal was gelesen dass jemand Solaris 11 Express oder so benutz hatte und es da keine AES Beschleunigung gab. Bei Solaris 11.1 soll es aber nun unterstützt werden und ist dementsprechend schneller
 
Zuletzt bearbeitet:
LUKS macht sich ziemlich in die Hose, wenn mein chronisch unzuverlässiger interner Kartenleser im Laptop mal wieder abtaucht. Auf der Basis würd ich mir kein ZFS drüberbauen wollen, das wär mir zu hässlich, wenn tatsächlich mal ne Platte abraucht.

Vorher Block Device, hinterher Block Device. Aber entweder mit mehr, oder mit größeren Blöcken, sonst brauch ich kein autoexpand. Kriegt z.B. LUKS das hin?

===
Das aktuelle Solaris macht Gebrauch von vorhandenen AES-Befehlssätzen. Eigentlich auch von SHA-Beschleunigung für die Hashes, aber das dürften nur die SPARCS beherrschen, etwas oberhalb von unsrem Budget hier ;)
 
Zuletzt bearbeitet:

Edit: Denkfehler meinerseits.

Vorher Block Device, hinterher Block Device. Aber entweder mit mehr, oder mit größeren Blöcken, sonst brauch ich kein autoexpand. Kriegt z.B. LUKS das hin?

Versteh ich grad nicht. Die Verschlüsselung wird doch pro Komponente gemacht. Wenn du eine größere Platte dazusteckst, wird die auch komplett verschlüsselt und du hast dann für ZFS ein block device mit mehr Blöcken als vorher. Wie sonst soll denn z.B. GELI oder LUKS bei ZFS funktionieren?

Dass sich LUKS jetzt irgendwie besabbert und Mist baut, davon bin ich erstmal nicht ausgegangen. Sowas kenn ich bei BSD nicht.
 
Zuletzt bearbeitet:
Man hat einen größeren Crypto-Overhead wenn die Blockdevices unterhalb von ZFS verschlüsselt werden.

Beispiel Schreibvorgang bei einem RAID1 Zpool:

Luks/Geli: Schreibvorgang -> ZFS -> Crypt(Festplatte1), Crypt(Festplatte2)
ZFS Crypto: Schreibvorgang -> ZFS Crypt -> Festplatte1, Festplatte2

Genauso verhält es sich auch wenn die Blöcke wieder gelesen werden.
 
Zuletzt bearbeitet:
Versteh ich grad nicht. Die Verschlüsselung wird doch pro Komponente gemacht. Wenn du eine größere Platte dazusteckst, wird die auch komplett verschlüsselt und du hast dann für ZFS ein block device mit mehr Blöcken als vorher. Wie sonst soll denn z.B. GELI oder LUKS bei ZFS funktionieren?
Hm. Nochmal durchdenken. Du tauscht dann also ZFS die Devices der Reihe nach unterm Hintern weg, oder mit replace auf das jeweils neue Device? Läuft das so?

Man hat einen größeren Crypto-Overhead wenn die Blockdevices unterhalb von ZFS verschlüsselt werden.

Beispiel Schreibvorgang bei einem RAID1 Zpool:

Luks/Geli: Schreibvorgang -> ZFS -> Crypt(Festplatte1), Crypt(Festplatte2)
ZFS Crypto: Schreibvorgang -> ZFS Crypt -> Festplatte1, Festplatte2

Genauso verhält es sich auch wenn die Blöcke wieder gelesen werden.
Der Overhead ist freilich da, Frage ist halt, wieviel das ausmacht. Mit hardwarebeschleunigtem AES ist das zeitlich eher unwichtig, außer auf SSD-Pools und/oder sehr dünn bemessenen CPUs. Da die Daten aber eh blockweise (je 16KB) durch AES geschoben werden, kann man die Sache einfachst parallelisieren, sodass ein großer Block gegenüber vielen kleinen pro Platte nicht unbedingt groß im Vorteil sein muss. Interessant wärs, wie das dann auf Plattenebene ankommt, denn ZFS kann doch blocksize variieren, auch unterhalb dieser 16K, oder?
 
Die Blocksize kann von 512byte bis 1024K variieren. Bei Pools mit ashift=12 liegt die minimal Blocksize bei 4k.
Der zusätliche Overhead bei luks/geli ist je nach vdev-typ unterschiedlich. Bei RAID1 muss alles doppelt verschlüsselt werden, bei RAIDZ wird der Stripe auf die anzahl der Platten aufgeteilt. Je nach RAIDZ-Level ensteht hier noch zusätzlicher overhead, da entweder ein, zwei oder drei Parity-Blöcke verschlüsselt werden.

Bei kleinen Pools wird man denke ich nichts davon bemerken, bei größeren Pools bestehend aus mehreren RAIDZ-Vdevs bin ich mir da nicht mehr so sicher.
 
Hm. Nochmal durchdenken. Du tauscht dann also ZFS die Devices der Reihe nach unterm Hintern weg, oder mit replace auf das jeweils neue Device? Läuft das so?

Das meinte ich mit x Blöcke vorher/x Blöcke hinterher (nach der Verschlüsselung). Alles was man bei ZFS mit block devices macht, geht mit verschlüsselten genauso. Die Verschlüsselung ist transparent.

Natürlich verschlüsselt man die redundanten Daten mit. Bei GELI zumindest profitiert man aber von mehreren Kernen, da alle Komponenten parallel behandelt werden können. Ob das bei ZFS-eigener Verschlüsselung auch so wäre, weiß ich nicht.
 
Welche SSDs sind für das ZIL zu empfehlen? Am wichtigsten sind dafür aus meiner Sicht die IOPS schreibend. Gibt es da eventuell performante Platten mit bspw. 16 GB o.ä.? Habe in dieser Hinsicht leider nichts finden können. Und eine bzw. zwei 60 GB+ Platte dafür einzusetzen, da sträubt es sich in mir. Dann könnte man nämlich schon fast darüber nachdenken, den Pool einfach gleich aus zwei SSDs aufzuziehen und auf das ZIL zu verzichten.

Soweit ich im Bilde bin, gibt es extra SSDs mit Energiepuffer, welche hierfür eingesetzt werden sollten.
 
Intel 710/DC S3700. Beide SSDs haben Kondensatoren um den Cache wegzuschreiben.

Je nach Workload könnte man die SSDs auch partitionieren, 8-16GB für ein ZIL-Mirror, den Rest für L2ARC.
 
Kann man ein Dataset eigentlich auch verschieben?

also von pool/dataset1/dataset2 => pool/dataset2
 
Das sollte mit "zfs rename pool/dataset1/dataset2 pool/dataset2" möglich sein
 
bin im internet über zfs rename -p gestoßen. Wofür steht das -p ?
illumos: manual page: zfs(1m) :
zfs rename [-fp] filesystem|volume filesystem|volume

Renames the given dataset. The new target can be located
anywhere in the ZFS hierarchy, with the exception of
snapshots. Snapshots can only be renamed within the
parent file system or volume. When renaming a snapshot,
the parent file system of the snapshot does not need to
be specified as part of the second argument. Renamed
file systems can inherit new mount points, in which case
they are unmounted and remounted at the new mount point.

-p

Creates all the nonexistent parent datasets.
Datasets created in this manner are automatically
mounted according to the mountpoint property inher-
ited from their parent.
 
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