[Sammelthread] ZFS Stammtisch

[gea]

Ok danke. Wo kann ich denn sehen, welche Größe "intern" verwendet wird? Hatte 4K oder 8k angegeben und nur leider vergessen was...

Gute Frage die ich aber jetzt auch nicht beantworten kann.
Normalerweise kann man Plattendetails mit prtvtoc oder parted abfragen.
ZFS and Advanced Format disks - illumos - illumos wiki

Lokale Platten ergeben damit aber die logical/physical Blocksize der Platten, Targets per Initiator dann 512B

Physikalisch muss man ja immer mit der tatsächlichen physical blocksize der Platten (meist 4k) arbeiten. Die Blocksize beim zvol bestimmt, in welchen "Päckchen" darauf geschrieben wird um damit Optimierungen für eine Anwendung vornehmen zu können. Vielleicht wäre das eine Frage an #illumos irc - wie liest man das nachträglich wieder aus?

vielleicht interessant als Ergänzung:
Sun's ZFS file system on Solaris ()

 

[zos]

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

Achja, es geht um iSCSI... Aber ein

zfs get volblocksize pool/volume

gibt Dir die (unter Napp-it mit unter Comstar/volumes/Create Volume angelegte) Blocksize des zvols und ein

stmfadm list-lu -v

sollte Dir doch die Blocksize der LU liefern, oder?

 

[CommanderBond]

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

Einsehen ja, aber wie kann man unter dem Menüpunkt etwas setzen?
Kann man da auch Sachen auskommentieren oder geht das nicht?

Hat sich irgendwas an den "Extensions" geändert? Habe meinen Server mal neu aufgesetzt aber alles ist deaktiviert, die waren doch mal 30 Tage free. Geändert oder ein Bug?

 

[besterino]

zfs get volblocksize pool/volume

stmfadm list-lu -v

sollte Dir doch die Blocksize der LU liefern, oder?

Jau... der zfs get volblocksize liefert das Gewünschte!

# zfs get volblocksize ZFSdata/iSCSIGames/iscsi_1460809272
NAME                                 PROPERTY      VALUE  SOURCE
ZFSdata/iSCSIGames/iscsi_1460809272  volblocksize  8K     -

Der stmfadm-Befehl ergibt die Ausgabe, die man auch im Napp-it menü unter comstar-->Logical Units mit Click auf die jeweilige LU bekommt:

# stmfadm list-lu -v
LU Name: 600144F070CC440000004C1460809272
    Operational Status     : Online
    Provider Name          : sbd
    Alias                  : ZFSdata/iSCSIGames
    View Entry Count       : 1
    Data File              : /dev/zvol/rdsk/ZFSdata/iSCSIGames/iscsi_1460809272
    Meta File              : not set
    Size                   : 1099511627776
    Block Size             : 512
    Management URL         : not set
    Vendor ID              : SUN
    Product ID             : COMSTAR
    Serial Num             : not set
    Write Protect          : Disabled
    Write Cache Mode Select: Enabled
    Writeback Cache        : Enabled
    Access State           : Active

Dankeschön! Wieder was gelernt! Ihr seid die Besten!

 

[gea]

Jau... der zfs get volblocksize liefert das Gewünschte!

Sieh an, an das Einfachste denkt man zuletzt.
Habe das in napp-it 16.04dev in die Übersicht zu den zvols eingebaut, macht Sinn.

 

[besterino]

Coolio!

 

[gea]

Einsehen ja, aber wie kann man unter dem Menüpunkt etwas setzen?
Kann man da auch Sachen auskommentieren oder geht das nicht?

Hat sich irgendwas an den "Extensions" geändert? Habe meinen Server mal neu aufgesetzt aber alles ist deaktiviert, die waren doch mal 30 Tage free. Geändert oder ein Bug?

SMB Parameter einstellen:
geht in der neuesten Version.
Davor werden alle Parameter lediglich angezeigt, setzen der Werte dann per cmd

Die 30 Tage Eval mit allen extensions ist verfügbar bei eine Neuinstallation
(sofern Internet geht)

Napp-it ist halt konstante Weiterentwicklung.
Alles wird nie in napp-it drin sein, dazu waren die Leute schon bei Sun bei der Entwicklung zu fleissig.
Und Illumos/ OmniOS ist ja auch nicht untätig. Nicht zu vergessen, Oracle Solaris, da muss auch dauernd was angepasst werden.

 

[CommanderBond]

Die 30 Tage Eval mit allen extensions ist verfügbar bei eine Neuinstallation
(sofern Internet geht)

Okay dann weiß ich aber nicht warum bei mir es nicht geklappt hat. Hab die OS SSD aber auch nicht formatiert extra nur frisch installiert.

 

[gea]

Kann ich so auch nicht sagen warum es nicht geklappt hat; nimm einfach den
complete evaluate - 17.05.2016::sPqmsqsmVlTTVPqmKqsmVlTTDKPP

 

[CommanderBond]

cool danke

 

[fdiskc2000]

Nabend,
ich nutze ZFS mit NappIT 16.02 und OmniOS15016 auf 2 Server. Der N40L ist der Backup Server. Wird extern morgens gestartet und soll dann zeitgesteuert die Replikation erstellen (extension Lizenz vorhanden). Warum auch immer schlägt das in der letzten Zeit immer fehl. Erst wenn ich den letzten Snap auf beiden lösche, klappt es genau einmal manuell. Der nächste Job klappt wieder nicht.
Das hier steht im Log:

error time: 2016.04.19.07.30.52 line: 1764 my_log end 1551: error,
next destination snap was not created
snap: backup/ESXI@1460884792_repli_zfs_THORA_nr_2 error, job-replicate 849: next destination snap was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs error, job-replicate 849: next destination snap was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs
end receive time: 2016.04.19.07.30.44 line: 852 zfs receive 1460884792 running 35 s
receiver message
time: 2016.04.19.07.30.44 line: 842
receive finished with warning 'failed to read from stream',
can be a message only: check if target snap is created time: 2016.04.19.07.30.44 line: 832
error, monitor info time: 2016.04.19.07.30.44 line: 262 replication terminated or not running: local nc and zfs receive=1, remote nc=,remote zfs send=
incremental send time: 2016.04.19.07.30.10 line: 968 Crest: zfs send -i NFS/ESXI@1460884792_repli_zfs_THORA_nr_1 NFS/ESXI@1460884792_repli_zfs_THORA_nr_2 | /var/web-gui/data/tools/nc/nc -b 262144 -w 40 192.168.178.12 55321
start receiver time: 2016.04.19.07.30.09 line: 812 /var/web-gui/data/tools/nc/nc -b 262144 -d -l -p 55321 | /usr/sbin/zfs receive -F backup/ESXI 2>&1
next replication time: 2016.04.19.07.30.02 line: 106

Ja beide sind online, finden sich im Netzwerk und sind in der appliance Group eingetragen.
Wenn ich den Backupserver leere und neu aufsetzte geht es 1-2 Mal und geht dann wieder schief.

Kann jemand das Log übersetzen? Ich erkenne keinen Fehler mehr.

 

[gea]

Die entscheidende Fehlermeldung ist
receive finished with warning 'failed to read from stream',
Das bedeitet das zfs receive mit dieser Fehlermeldung beendet wurde

Der Rest beschreibt nur den Ablauf (neueste Meldung oben)
- Starte Receive
- Starte Send
- Starte Monitoring
- Receiver läuft noch, Send aber nicht mehr (Monitor)
- Receive wird beendet, aber Fehlgeschlagen (kein neuer Snapshot)

Ursachen
Nicht so einfach festzustellen, mögliche Ursachen
- Netzwerkproblem
- Send kann nicht gestartet werden, z.B. Platte voll oder zuviel Snaps (timeout)
- Zpool busy (warum auch immer)
- letzter Snap wurde verändert, z.B. durch autosnaps mit delete zero snaps

gibt es denn irgendwelche Hinweise z.B. in den System-Logs.
Wenn mehrere Replikationen und autosnaps laufen, diese eventuell zeitversetzt starten

Ansonsten kann man den Ablauf auf beiden Seiten im Menü Jobs -Remote bzw Monitor
kontrollieren.

 

[fdiskc2000]

Netzwerk sollte passen
Platten/Pools haben jeweils >1TB frei
Auto-Snaps haben Hold60, dürfte auch nicht das Problem sein.
keine delete zero snaps aktiv, wird ja auch so empfohlen

Job-Monitor-Backupserver:
1460884792 error
job-replicate 1331 21.17:44 job-replicate.pl &log 1768 <- job-replicate.pl &my_log 1528 <- job-replicate.pl &my_end_all 1497 <- job-replicate.pl &my_fast_end 901 <- job-replicate.pl &my_remote_delta_replication 366
end log error,
next destination snap was not created
snap: backup/ESXI@1460884792_repli_zfs_THORA_nr_2 error, job-replicate 849: next destination snap was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs error, job-replicate 849: next destination snap was not created, check network, systemlog, poolstate, capacity, timeouts and (hidden) snaps
on recursive transfers check if newest snappairs on source target are consistent - optional delete incomplete newest pairs
1460884792
job-replicate 630 21.17:36 job-replicate.pl &log 851 <- job-replicate.pl &my_remote_delta_replication 366 <- job-replicate.pl &my_run 126
end receiver after 35 s ¨ ¨
1460884792
job-replicate 741 21.17:03 job-replicate.pl &log 1012 <- job-replicate.pl &my_remote_delta_replication 366 <- job-replicate.pl &my_run 126
send via job-repli-send.pl (), used=79.9M,0
1460884792
job-replicate 21.17:02 job-replicate.pl &log 969 <- job-replicate.pl &my_remote_delta_replication 366 <- job-replicate.pl &my_run 126
start sender init remote send id=1460884792
src_interface=/usr/bin/nc -w 40 192.168.178.12 55321
src_interface2=/var/web-gui/data/tools/nc/nc -b 262144 -w 40 192.168.178.12 55321
snap_name1=NFS/ESXI@1460884792_repli_zfs_THORA_nr_1
snap_name2=NFS/ESXI@1460884792_repli_zfs_THORA_nr_2
send_inc=-i
snap_rec=
send_rec=
send_dedup=
send_i=-i
transfer_zero=
1460884792
job-replicate 449 21.17:01 job-replicate.pl &log 678 <- job-replicate.pl &my_remote_delta_replication 366 <- job-replicate.pl &my_run 126
request remote snaps NFS@tglich-1460016392_2016.04.08.00.00.07 0 - 128K,NFS@tglich-1460016392_2016.04.09.00.00.06 0 - 128K,NFS@tglich-1460016392_2016.04.10.00.00.08 85.2K - 128K,NFS@tglich-1460016392_2016.04.11.00.00.07 85.2K - 128K,NFS@stndlich-1460016338_2016.04.12.00.00.07 0 - 128K,NFS@tglich-1460016392_2016.04.12.00.00.07 0 - 128K,NFS@stndlich-1460016338_2016.04.12.01.00.07 0 - 128K,NFS@stndlich-1460016338_2016.04.12.02.00.07 0 - 128K,NFS@stndlich-1460016338_2016.04.12.09.00.06 0 - 128K,NFS@stndlich-1460016338_2016.04.12.10.00.06 0 - 128K,NFS@stndlich-1460016338_2016.04.12.11.00.06 0 - 128K,NFS@stndlich-1460016338_2016.04.12.12.00.06 0 - 128K,NFS@stndlich-1460016338_2016.04.12.13.0 ¨ ¨
1460884792
job-replicate 255 21.16:59 job-replicate.pl &log 365 <- job-replicate.pl &my_run 126
start replication
remote incremental Crest -> THORA
NFS/ESXI -> backup/ESXI


Job Monitor Main:
glib grouplib_remote_call_destroy_snap 1311 21.19:09 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_destroy_snap 701 <- admin.pl &grouplib_remote_call 126
request destroy snap 192.168.178.12 ¨ zfs destroy NFS/ESXI@1460884792_repli_zfs_THORA_nr_2
noid 21.19:09 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_destroy_snap ¨ ¨
## noid 21.19:05 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_zfslist 683 <- admin.pl &grouplib_remote_call 126
glib 1067
grouplib_remote_call_zfslist request zfslist (snapshots) 192.168.178.12 ¨ |
noid 21.19:04 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_zfslist ¨ ¨
## noid 21.19:03 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_pslist 676 <- admin.pl &grouplib_remote_call 126
glib grouplib_remote_call_pslist 986 request pslist 192.168.178.12 714 /var/web-gui/data/tools/rsync/rsync --daemon --config /var/web-gui/_log/rsyncd.conf
noid 21.19:03 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_pslist ¨ ¨
## noid 21.18:32 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_pslist 676 <- admin.pl &grouplib_remote_call 126
glib grouplib_remote_call_pslist 986 request pslist 192.168.178.12 714 /var/web-gui/data/tools/rsync/rsync --daemon --config /var/web-gui/_log/rsyncd.conf
noid 21.18:32 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_pslist ¨ ¨
noid 21.18:29 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_zfs_send 689 <- admin.pl &grouplib_remote_call 126
glib grouplib_remote_call_zfs_send 1291
request snapdel 192.168.178.12 ¨ zfs snapshot NFS/ESXI@1460884792_repli_zfs_THORA_nr_2
noid 21.18:29 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_zfs_send 689 <- admin.pl &grouplib_remote_call 126
glib grouplib_remote_call_zfs_send 1286
request snapdel 192.168.178.12 ¨ delete NFS/ESXI@1460884792_repli_zfs_THORA_nr_2
noid 21.18:29 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_zfs_send ¨ ¨
## noid 21.18:28 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_get_my_ip 695 <- admin.pl &grouplib_remote_call 126
glib 1200 remote call get my ip ¨ from 192.168.178.12
noid 21.18:28 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_get_my_ip ¨ ¨
## noid 21.18:27 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_zfslist 683 <- admin.pl &grouplib_remote_call 126
glib 1067
grouplib_remote_call_zfslist request zfslist (snapshots) 192.168.178.12 ¨ |
noid 21.18:27 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_zfslist ¨ ¨
## noid 21.18:26 _lib _lib/illumos/grouplib.pl &grouplib_remote_call_zfslist 683 <- admin.pl &grouplib_remote_call 126
glib 1067
grouplib_remote_call_zfslist request zfslist () 192.168.178.12 ¨ |
noid 21.18:26 _lib/illumos/grouplib.pl &log 652 <- admin.pl &grouplib_remote_call 126
grouplib 889 remote call do=
request_zfslist ¨ ¨

Sorry, kann man das irgendwie übersichtlicher kopieren?
Warum wir denn am Ende ein zfs destroy auf den snap ausgeführt?
Habe eben den Snap manuell mit dem Befehl erzeugt, das macht er ohne Probleme.

- - - Updated - - -

Ich beisse gerade in die Tischkante, nachdem ich den Job gefühlt das 5. mal manuell gestartet habe, läuft die Replikation wieder durch. Und auch ein weitere Start danach klappt fehlerfrei. Ich würde nur gerne verstehen, warum auf einmal und was vorher nicht geklappt hat?

 

[gea]

Logfiles z.B. unter "Erweitert" als Code einkopieren,
dann bleiben die Zeilenumbrüche erhalten.

Anosnsten

zfs send - zfs receive klingt zunächst sehr einfach.
In der Praxis gibt es viele mögliche Probleme die alle nur in "failed to read from stream" enden
Wenn die Meldung "Snaps passen nicht" lautet, dann ist es einfacher.

Das ist auch der Grund, warum ich jeden Schritt im Ablauf protokolliere -
zumal ZFS replikation ja auch bei OmniOS ständig neue Features erhält.
Das ist daher etwas an dem ich immer wieder etwas anpassen muss.
(Ich habe aktuell auch zwei von 10 Servern, bei denen die Replikation ab und an Fehler liefert
ohne dass ich die Ursache bisher eindeutig eingrenzen kann)

Daher nach Möglichkeit, die napp-it Version gleich und aktuell halten.

 

[fdiskc2000]

Ok, danke Dir. Werde schauen ob es nun morgen früh wieder durchläuft ohne Fehler.
Versionen sind aktuell und gleicher Stand.

 

[gea]

An die Replikation muss ich eh demnächst wieder ran
da es dazu einige Erweiterungen in OmniOS gibt.

 

[fdiskc2000]

Das wäre top

 

[gea]

Info zum Napp-it ToGo ZFS Storage Server
Ich habe neue Images hochgeladen (frei verfügbar).

OmniOS 151018 mit SMB2 und napp-it 16.02f,
Base-Tuning, TLS Alert Emai z.B. an Gmail. Alle Nics werden automatisch auf DHCP konfiguriert


Napp-it ToGo Sata
Das sind Images für eine Installation direkt auf Hardware auf eine Sata Platte.
Nach dem Zurück-Clonen der Images auf eine Systemplatte kann man direkt loslegen.

Die Images sind für eine Kingston V300-60G oder Intel S3510-80G mit Powerloss Protection gedacht.
HowTo: http://www.napp-it.org/doc/downloads/napp-it.pdf

Die Images wurden auf einem SuperMicro X11-SSH-CTF erstellt und laufen auch oft auch
auf anderen Boards oder Systemen. Wenn die jemand auf einem anderen System, z.B. HP oder Dell
installiert hat und es läuft, bitte ich um eine kurze Rückmeldung an community@napp-it.org


Napp-it ToGo VM
Das sind Images für ein virtualisiertes SAN oder NAS unter ESXi
Die kann man fertig konfiguriert direkt in ESXi importieren
HowTo: http://www.napp-it.org/doc/downloads/napp-in-one.pdf

Aktuelles Image 2016.04 für ESXi 5.5U2 - 6.0U2
Open-VM-Tools mit vmxnet3s und MTU9000

Die Open-VM-Tools sind neu in OmniOS 151018 dabei.

 

[CommanderBond]

Was heist Base Tuning genau? Was wurde geändert?

 

[gea]

Die Grundeinstellungen von Solaris/ OmniOS sind optimiert für 1G Netzwerk und wenig RAM.
In den Images habe ich Einstellungen für schnellere Netzwerke und ausreichend RAM vorgenommen.

Zu den Einstellungen.
Im Menu System > Tuning kann man entweder das "Base Tuning" aktivieren oder eigene Einstellungen
vornehmen. Die Einstellungen betreffen TCP Buffers, NFS Buffers, NFS Servereinstellungen, MTU Settings,
ESXi vmxnet3 Optimierungen aber auch Sata Hotplug, Arc Cache Settings oder Disk Timeouts.

Die genauen Einstellungen kann man dort ablesen, ändern oder resetten.

 

[CommanderBond]

mal ne frage zu den snapshots: 0 Byte Snapshots werden nur gelöscht wenn die im selben Job erstellt worden sind oder? Wenn ich einmal beispielsweise um 23Uhr einen Snap erstellen lasse und durch einen anderen Job um 23:15 immer, so wird der heutige 23Uhr snapshot nicht gelöscht auch wenn er 0byte groß ist? Und quasi keine Veränderung zum 23:15 Snapshot besitzt?

 

[fdiskc2000]

Korrekt. Zumindest in nappit gibt es einen Parameter dafür. Deletezero oder so ähnlich. Laut Doku soll man den aber ausgeschaltet lassen, wenn auf dem Dateisystem auch ein repli Job läuft. Wobei ich nicht verstehe warum das nicht auch parallel geht, da normaler Snap und repli Snap ja Unterschiedliche Bezeichnungen und jobid haben.


Gesendet von iPhone mit Tapatalk

 

[CommanderBond]

Dass es delzero gibt weiß ich ja. Meine Frage/Anmerkung war ja dass es eben nicht Job übergreifend funktioniert.

 

[morumbinas]

Ich habe vor ZFS auf meinem ESXi Host (HP Microserver) einsetzen (mit der Napp it Lösung). Aktuell liegen alle meine Files auf einer einzigen Sata HDD und ich würde zusätzlich gerne noch auf ein Raid1 setzen.

Welchen Sata Raid Controller den ESXi unterstützt könnt Ihr mir empfehlen (günstig, gerne auch eBay etc.)? Wird alles privat eingesetzt, also ich brauche keine Enterprise Lösung. Ein Software Raid ist anscheinend ja mit ESXi nicht möglich.

Vielen Dank für Vorschläge


. Aktuell liegen meine Files auf einer einzigen HDD, würde gerne auf Raid1 umsteigen.

 

[morph027]

ZFS beisst sich mit RAID Controller...also kannst du einfach den normalen onboard nehmen und in den AHCI Modus schalten. Das RAID1 macht dann dein ZFS (in den in die VM durchgeschleiften Platten).

 

[morumbinas]

ich hätte gedacht (soweit ich noch weiß war das hier im forum von gea) das man mit einem hardware raid controller besser fährt (falls es nicht stimmt, dann steinigt mich ).

Der esxi host soll sämtliche aufgaben erledigen, d.h. u.a. Fileserver, Firewall und auch Backupserver.

 

[Handle]

Entweder direkt ans Mainboard oder an einen HBA mit IT-Modus / Firmware. ZFS braucht direkten Zugriff auf die Festplatten ohne einen Controller, der zwischendrin sein eigenes Ding macht.

 

[gea]

ich hätte gedacht (soweit ich noch weiß war das hier im forum von gea) das man mit einem hardware raid controller besser fährt (falls es nicht stimmt, dann steinigt mich ).

Der esxi host soll sämtliche aufgaben erledigen, d.h. u.a. Fileserver, Firewall und auch Backupserver.

Ein Hardwareraid könnte man für ESXi und den lokalen Datastore mit vmfs Dateisystem machen. Solange darauf aber nur die Storage VM ohne weitere Dienste liegt, macht das wenig Sinn da die einfach umd schnell wiederherstellbar ist.

Für ZFS sollte man nie ein Hardwareraid nehmen. Die Prüfsummen von ZFS könnten dann zwar immer noch Fehler entdecken aber ZFS kann die nicht mehr reparieren.

Man muss sich aber Geanken machen, wie man die Platten an die NAS-Storage VM anschließt. Geht zwar zur Not mit RDM, auch könnte man die Storage VM auf USB legen und Sata durchreichen, die einzig eirklich saubere Lösung ist aber ein eigener LSI HBA Controller den man per pass-through durchreicht und darauf den ZFS Pool legt. Auf dem ZFS Pool liegen dann normale SMB Sachen und weitere ESXi VMs auf einem NFS Datastore.

 

[automatenraum]

Wie sieht es bei OmniOS 151018 mit NFS Bugs bzw. Disconnects der NFS Datastores aus, also den Problemen, die es mal bei älteren OmniOS Versionen gab?

 

[gea]

Ich habe 151018 im Testbetrieb auf 2 AiO Servern und konnte bisher nichts festellen.
Aber auch bei älteren Versionen gab es keine generellen Probleme.

Die Probleme wie z.B. hier beschrieben https://forums.servethehome.com/ind...unstable-consistent-apd-on-vm-power-off.6099/ waren spezifische Probleme und die Ursache nach wie vor nicht ganz klar.

In letzter Konsequenz ist fast jede Hardware und Softwarekonfiguration unterschiedlich.
Für professionellen Einsatz würde ich bei größeren Updates daher mmer eine Testphase voranstellen und erst dann in den Produktivbetrieb gehen (wobei Updates bei Solaris dank der Bootenvironments relativ unkritisch sind. Man kann ja jederzeit einen älteren Stand booten)