[Sammelthread] ZFS Stammtisch

[gea]

napp-it 17.01 nutzt reines css zur Menüdarstellung, vorher war das alles Javascript.
Die obige Darstellung ergibt sich wenn man css ausschaltet, einen sehr alten Browser nutzt oder die vorherige css noch im Cache liegt.

Ich vermute letzteres. Dazu mal Page reload (F5) aufrufen oder mit einem anderen Browser vergleichen.
Manche Browser halten css recht lange und hartnäckig im Cache.

 

[TCM]

Shift+Reload forciert ungecachte Requests.

 

[phaus]

Ich verwende nun schon seit meheren Jahren ZFS und konnte nun auch schon ein paar Erfahrungen mit Produktivsystemen sammeln.
Ein kleines Setup lässt sich durch zwei kleine SSDs beschleunigen, wenn man weiß, dass öfters mal größere Datenmengen wiederholt gelesen werden, oder einfach nicht genug RAM (<32GB) im System vorhanden ist.
ZFS verwendet, wie bereits schon erwähnt, einen Schreib-Cache (ZIL), aber auch einen Lesecache.

Auf kleineren Hosts habe ich meisten zwei SSDs paritioniert und jweils als Mirror für ein ZIL und als stripe für den Lesecache verwendet.

Das sieht dann z.B. so aus:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda2 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
sdd ONLINE 0 0 0
sde ONLINE 0 0 0
logs
mirror-2 ONLINE 0 0 0
sdf1 ONLINE 0 0 0
sdc1 ONLINE 0 0 0
cache
wwn-0x600508b1001c12f84a62be758b0f2065-part2 ONLINE 0 0 0
wwn-0x600508b1001c5be0aa38b2d9e145c248-part2 ONLINE 0 0 0


Auf einem recht neuen System mit ein paar VMs drauf sieht die Cache Statistik dann so aus:

capacity operations bandwidth
pool alloc free read write read write
---------------------------------------------- ----- ----- ----- ----- ----- -----
rpool 169G 1.65T 1 33 149K 174K
mirror 84.8G 843G 0 14 74.3K 70.8K
sda2 - - 0 6 37.7K 77.6K
sdb2 - - 0 6 36.7K 77.6K
mirror 84.7G 843G 0 19 74.5K 95.8K
sdd - - 0 8 37.7K 104K
sde - - 0 7 36.9K 104K
logs - - - - - -
mirror 420K 3.72G 0 0 0 7.27K
sdf1 - - 0 0 0 7.27K
sdc1 - - 0 0 0 7.27K
cache - - - - - -
wwn-0x600508b1001c12f84a62be758b0f2065-part2 39.7G 8.74G 0 0 157 42.6K
wwn-0x600508b1001c5be0aa38b2d9e145c248-part2 39.9G 8.52G 0 0 148 42.6K
---------------------------------------------- ----- ----- ----- ----- ----- -----

Das System hat aktuell 72GB RAM (wobei ZFS nur 32GB zur Verfügung stehen).

Die SSD haben jeweils eine 4Gb Partition für den ZIL Mirror und 50Gb für den Lesecache.
Die korrekte Größe der SSDs sind 240Gb, aber theoretisch sollte der SSD Controller dann mehr freie Zellen zur Verfügung haben um ein wearout zu verzögern.

 

[gea]

ZFS verwendet, wie bereits schon erwähnt, einen Schreib-Cache (ZIL), aber auch einen Lesecache.

Auf kleineren Hosts habe ich meisten zwei SSDs paritioniert und jweils als Mirror für ein ZIL und als stripe für den Lesecache verwendet.

Das sieht dann z.B. so aus:
..

Kleine Korrektur damit keine Verwirrung wegen der sehr oft unterschiedlichen Handhabung der Begriffe aufkommt

Ein ZIL puffert die letzten Sekunden der bestätigten Schreibvorgänge gegen Crash. Dies geschieht aber zusätzlich zum ZFS Schreibcache im RAM. Es ist daher ein zusätzliches Logdevice, von der Funktion wie bei Hardwareraid der Cache mit Batterie. Mit einem Schreibcache wird allgemein etwas anderes assoziert - dass die normalen Schreibaktionen damit gepuffert werden- und das ist ein ZIL nicht.

Ein Zil ist auch immer ein zusätzliches Logging - Device auf dem normalen Datenpool.
Eine Zil Funktionalität auf einem Extra Laufwerk heißt Slog wie Separates Logdevice

Ein Slog kann man spiegeln. Damit gibt es in erster Linie keinen Performanceeinbruch falls das ausfällt. Auch führt der extrem seltene Fall eines Defekts beim Schreiben mit Crash nicht zu einem Datenverlust.

Das L2Arc als Erweiterung des rambasierten Lescaches ist nicht gestript. Wenn man mehr als eine SSD als L2Arc nutzt so passiert sowas wie ein load-balancing, keine sequentielle Beschleunigung wie beim Stripen.

 

[Digi-Quick]

Moin,
wenn ich das Storage OS von Nas4Free (FreeBSD) auf OmniOS/Napp-It wechsle, dann müsste (zumindest theoretisch) die ZFS Konfiguration (VDEVs, Pools und Volumes/Datasets) übernommen werden.
ABER: was passiert mit einem iSCSI Target?
Ich schätze mal, daß dieses nicht automatisch erkannt wird.
Wenn ich das Target mit den gleichen Kennwerten (Name, Grösse etc.) unter Napp-It einrichte ist das Dateisystem auf dem Target wohl trotzdem weg oder?

Hat das schonmal jemand gemacht, kann was dazu sagen?

 

[gea]

Ich hab das zwar noch nicht gemacht, pool export/import sollte aber zwischen allen Open-ZFS Plattformen (BSD, Linux, OSX, Solarish/Illumos) gehen:

Probleme kann es geben, wenn man nicht die ganze Platte für ZFS genutzt hat.
Anschliessend stehen die Dateisysteme und zvols zur Verfügung.

- iSCSI Targets werden von anderen Services verwaltet.
Die werden garantiert nicht übernommen.

Wenn ein zvol (ein ZFS Dateisystem als Blockdevice) die Grundlage des Targets war, könnte man versuchen es in Solarish als Logical Unit zu importieren.
Bei Solarish (Comstar) müsste man dann ein Target anlegen und ein View von der Logical Unit auf alle Targets setzen. Das Ergebnis würde mich auch interessieren,

 

[Digi-Quick]

Da wird wohl der Hase im Pfeffer liegen.
Das iSCSi Target ist kleiner als das zVol, vermutlich wegen der ZFS Reservierung (220G von 227G)

Eigentlich würde mich das schon sehr wundern, wenn das klappen würde

 

[effemmess]

Nee, der Hase liegt nicht im Pfeffer sondern vor nem Baum und sieht den Wald nicht!
Klar geht das. Ich kenn jetzt zwar nicht die NAS4free-Besonderheiten, aber ich wüsste auch keinen Grund warum es nicht gehen sollte.
Ich habe bis ESX 5.5 Infiniband-SRP auf zvols benutzt - also quasi wie iscsi. Da habe ich auch zvols bzw. pools repliziert und anschließend als SRP-(iscsi-)Target wieder eingebunden. Ich weiß nur nicht mehr, ob ich damals mir die Mühe der gleichen Bezeichnung gemacht hab... Und ich weiß auch nicht mehr, ob der ESX dies als Original-Target anerkannt hat. Ich glaube mich aber zu erinnern, dass ich die iscsi-Multipath-Features des ESX genutzt hatte... Im schlimmsten Fall müssen die VMs neu importiert werden...

Wo kommt bei dir auf einmal die Reservierung her? Nach Export/Import ändert sich am Pool und damit am zvol rein gar nichts.
Probierts doch einfach mal aus! So ein File-zvol ist doch schnell angelegt...

- - - Updated - - -

Thema NVMe-ESXi-Passthrough

Der commit ist grade in Ilumos gelandet ...

cu

Ich hab grad n frisches OmniOS mit ner frisch gezogenenen ISO aufgesetzt und gleich nochmal geupdatet. Da kam 1 - in Worten ein - Update. Leider stand da nirgends, was das war...
Auf jeden Fall hab ich schnell ne NVMe per passthrough reingehängt und nen Schnelltest gemacht. Es sieht gut aus...
Also entweder auf der neuen ISO muss der neue Treiber sein oder es war das eine Update... egal - es geht nun wohl!

 

[gea]

zu NVMe Pass-through in ESXi

Ich hab's gerade getestet da ich auch darauf warte dass der Fix in OmniOS landet.
Bei mit hängt ein mehrfaches Format Kommando nach wie vor.

In Timeline oder in omnios-discuss ist dazu auch noch nichts vermerkt.

 

[ludwinator]

hier ist es drin.

cu

 

[effemmess]

zu NVMe Pass-through in ESXi

Ich hab's gerade getestet da ich auch darauf warte dass der Fix in OmniOS landet.
Bei mit hängt ein mehrfaches Format Kommando nach wie vor.

In Timeline oder in omnios-discuss ist dazu auch noch nichts vermerkt.

Hmmm , bei mir geht es auf 2 unterschiedlichen Systemen problemlos...
IBM x36xx mit ESXi 5.5 und 1TB Samsung SM961
HP DL360 G6 ESXi 6.0 und 512GB Samsung SM961

bloody-ISO vom 17.1.
/kernel/drv/amd64/nvme 57976 Jan 17 23:46

root@testsan7:~# cat  /kernel/drv/nvme.conf
...
# The driver was tested only against devices supporting v1.0 of the
# NVMe specification. Uncomment this to be able to use devices conforming
# to newer specifications.

strict-version=0;

Das Problem äußerte sich zuletzt ja immer so, dass bei einem Zugriff auf die nvme z.B. durch format die komplette VM sich aufhängt. Allerdings nur nach poweroff. Nach einem reboot gab es schon länger keine Probleme mehr.
Wie gesagt, bei mir funktionierts auch nach poweroff...

- - - Updated - - -

hier ist es drin.

cu

Ohhh
D.h. es hätte auch schon vor dem 17.1. per pkg update funktionieren sollen???
Hat es aber definitiv nicht.
Ich blick da nicht mehr (bzw. noch nie) ganz durch, wann welche Änderung in Nexenta/Illumos/OmniOS erfolgt ist.Aber egal...

 

[gea]

Ohhh
D.h. es hätte auch schon vor dem 17.1. per pkg update funktionieren sollen???
Hat es aber definitiv nicht.
Ich blick da nicht mehr (bzw. noch nie) ganz durch, wann welche Änderung in Nexenta/Illumos/OmniOS erfolgt ist.Aber egal...

Illumos ist der freie Fork von Solaris und die gemeinsame Entwicklerlinie von Firmen wie Delphix, Joyent, Nexenta oder OmniTi oder Projekten wie OpenIndiana oder mehreren anderen. Die pflegen aber alle zusätzlich eine eigenen Zweig von Illumos. Manche der Entwicklungen bleiben in diesem privaten Zweig, andere werden von diesen ins gemeinsame Illumos integriert (Beispiel SMB2 von Nexenta). Prinzipiell steht es jedem offen, Teile aus anderen Zweigen in einen eigenen Zweig zu übernehmen (Beispiel Linux zones von SmartOS nach OmniOS) oder in das gemeinsame Illumos Dach zu integrieren.

Zwar enthält Illumos deutlich mehr als nur den Kernel (z.B. Services wie SMB, NFS, Comstar iSCSI, Network Virtualisation, Userland Tools etc), dennoch ist das Konzept ähnlich wie bei Linux wo der Kernel gepflegt wird im Verhältnis zu den darauf aufbauenden Distributionen wie CentOS oder Debian.

Treiberupdates wie hier wandern zuerst in das gemeinsame Illumos Projekt und werden dann in die Distributionen integriert, im Fall vom OmniOS oft zuerst in die bloody release, dann in die Stable. Ich habe meinen Test mit der aktuellen 151020 stable gemacht. Änderungen da werden auch im Changelog genannt. Änderungen in der Bloody sind aber noch nicht dokumentiert.

Sollte der NVMe Fix in der Bloody sein was das Datum des Treibers mit 17.1.2017 ja nahelegt, hoffe ich dass das noch vor Erscheinen der 151022 auch in die aktuellen Stable übernommen wird.

 

[Digi-Quick]

Wo kommt bei dir auf einmal die Reservierung her? Nach Export/Import ändert sich am Pool und damit am zvol rein gar nichts.

Keine Ahnung warum, ich konnte das ZFS Volume nicht in voller Grösse des Pools anlegen.

Pool-Exch-Data

238G

Vol-Exch-Data

220G

 

[ludwinator]

Offensichtlich hat das Problem mit format nichts mit msi-x zu tun, siehe: Bug #7804: fdisk_read_master_part_table() causes to crash - illumos gate - illumos.org

cu

 

[effemmess]

Keine Ahnung warum, ich konnte das ZFS Volume nicht in voller Grösse des Pools anlegen.

Ahhh, du hast ja den Pool neu angelegt, damit ist natürlich der Originalpool mitsamt Einstellungen futsch. Bei einem einfachen Import wäre der pool und das zvol einfach wieder da...

- - - Updated - - -

Offensichtlich hat das Problem mit format nichts mit msi-x zu tun, siehe: Bug #7804: fdisk_read_master_part_table() causes to crash - illumos gate - illumos.org

cu

Das dort beschriebene Problem kann ich so mit meinen 3 unterschiedlichen Samsung-NVMe´s nicht bestätigen...
Mit altem Treiber blieb die VM beim ersten Zugriff auf die NVMe (egal ob format oder anderweitig) komplett stehen, in keiner Konsole war eine Ein- oder Ausgabe möglich. Es blieb nur hartes Ausschalten der VM. Der Entwickler des nvme-Treibers hat sich dann zur Problemanalyse auf meine Kiste geklinkt und eben dieses MSI-X-Problem festgestellt...
@gea: Wie haben sich deine Abstürze geäußert?

Ansonsten kannte ich andere Probleme mit falscher Sektorgröße... Nach dem standardmäßigem Partitionieren und Pool anlegen kam es zu massiven Checksum-Fehlern. Ashift=12 über die sd.conf geht nicht, da die nvme über den nvme-Treiber als blkdev angesprochen wird. Daher hatte ich damals die Parition und den pool unter zfsguru manuell erstellt, exportiert und unter omnios wieder importiert. Da der o.g. Fehler auch nur nach einem Kaltstart der VM auftrat, konnte ich somit damals sogar mit dem ganz alten Treiber stabil in meiner Home-/Testkiste arbeiten.
Ich werde mir die Tage nochmal genauer anschauen, wie OmniOs denn nun mit dem aktuellen Treiber die Sektorgrößen behandelt...

Ich seh grad, bei dem Bug 7804 gehts auch gar nicht um ESXi-Passthrough...
Komisch finde ich dennoch, dass seine P3700 als drive type unknown erkannt werden.

# format
Searching for disks...done

AVAILABLE DISK SELECTIONS:
       0. c1t1d0 <drive type unknown>
          /pci@0,0/pci8086,6f04@2/pci8086,3703@0/blkdev@1,0

Bei mir steht das so:

root@san-04:~# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c3t0d0 <VMware-Virtual disk-1.0 cyl 2607 alt 2 hd 255 sec 63>
          /pci@0,0/pci15ad,1976@10/sd@0,0
       1. c4t1d0 <SAMSUNG-MZVKW512HMJP-00000-CXA7100Q-476.94GB>
          /pci@0,0/pci15ad,7a0@16/pci144d,a801@0/blkdev@1,0
Specify disk (enter its number):

 

[Digi-Quick]

Ahhh, du hast ja den Pool neu angelegt, damit ist natürlich der Originalpool mitsamt Einstellungen futsch. Bei einem einfachen Import wäre der pool und das zvol einfach wieder da...

irgendwann muß man wohl einen Pool anlegen, den man nutzen möchte.
- VDEV anlegen
- Pool Anlegen
- Dataset oder Volume anlegen
Datasets gehen über die Volle Größe des Pools >> 1 Dataset pro Pool
Volumes können zumindest bei N4F nicht in voll Poolgrösse angelegt werden, zumindest nicht ohne thin provisioning (sparse volume). >> mehrere Volumes pro Pool möglich
ein SCSI Target kann nur aus einem Volume erstellt werden.

Das ich die ZFS Geschichten importiert bekomme sehe ich als gegeben an, da sowohl N4F als auch OmniOS Open-ZFS nutzen.

 

[supemole]

Eine Frage zu COMSTAR und iSCSI

Ich habe ein COMSTAR Volume erzeugt und über iSCSI von einem Client gemountet. Ich möchte nun täglich einen Snapshot von diesem Volume machen und diesen Snapshot dann an einen Backup Server senden. Werden auch bei iSCSI Volumes nur die geänderten ZFS Blöcke zwischen zwei Snapshot gesendet? Also verhält sich das ganze genauso wie bei einem normalen ZFS Filesystem?

 

[gea]

Der Begriff "Comstar Volume" ist nicht ganz eindeutig.

Ein iSCSI Target baut auf einem Logical Unit auf. Das ist eine RAW Platte, eine Datei oder ein Zvol.
Wird ein Zvol benutzt, so handelt es sich dabei um ein ZFS Dateisystem das als Blockdevice, quasi wie eine Festplatte verwaltet wird.

Dieses "spezielle" ZFS Dateisystem kann man ganz normal per zfs send basierend auf incrementellen Snapshot replizieren - genauso wie ein "normales" ZFS Dateisystem.

 

[supemole]

Der Begriff "Comstar Volume" ist nicht ganz eindeutig.

Ein iSCSI Target baut auf einem Logical Unit auf. Das ist eine RAW Platte, eine Datei oder ein Zvol.
Wird ein Zvol benutzt, so handelt es sich dabei um ein ZFS Dateisystem das als Blockdevice, quasi wie eine Festplatte verwaltet wird.

Dieses "spezielle" ZFS Dateisystem kann man ganz normal per zfs send basierend auf incrementellen Snapshot replizieren - genauso wie ein "normales" ZFS Dateisystem.

Ja sorry, es ist ein Zvol. Besten Dank!

 

[CommanderBond]

Das AMP Script funktioniert irgendwie nicht mehr mit dem neuesten OmniOS
Gibt es irgendwelche anderen Wege auf einem OmniOS eine VM einzurichten wenn OmniOS das Hostsystem ist? Will mein UniFi Controller irgendwie dort laufen lassen.

 

[zos]

Du kannst gern mal die neueste Version des amp-Scriptes (erfolgreich getestet in einer OmniOS r151020-VM) ausprobieren:
wget -O - http://www.wp10455695.server-he.de/amp | perl

Ebenfalls aktualisiert sind:
http://www.wp10455695.server-he.de/phpvbox (Derzeit VirtualBox-Version 5.0.32, die aktuellere 5.1.14 muss gepatcht werden um unter OmniOS zu laufen, das habe ich noch nicht ins Script integriert)
http://www.wp10455695.server-he.de/owncloud
http://www.wp10455695.server-he.de/nextcloud
http://www.wp10455695.server-he.de/pydio

Noch nicht fertig ist ein aktuelles serviio-Script.

 

[MaxRink]

VirtualBox kann man sich doch schenken, OmniTi hat ja KVM in OmniOS gemerged

Gesendet von meinem ZTE A2017G mit Tapatalk

 

[gea]

zur Virtualisierung mit OmniOS

Wenn es sich um Linux VMs handelt, so heißt die interessanteste Option lightweight LX Container in OmniOS. Das wurde von OmniTi gerade aus SmartOS übernommen. Momentan ist das noch Beta state in 151020, soll aber als stable in das nächste OmniOS 151022 im Sommer, Diskussion z.B. OmniOS now includes LX support (from Joyent/SmartOS) | ServeTheHome and ServeThe.Biz Forums

Wenn es sich um andere VMs handelt, z.B. Windows dann ist Virtualisierung des Gesamtsystems unter ESXi unschlagbar schnell und effizient.

@zos
Klasse!

 

[zos]

VirtualBox kann man sich doch schenken, OmniTi hat ja KVM in OmniOS gemerged

Nun, es gibt halt verschiedene Anwendungsszenarien. Möglicherweise gehöre ich zu einer Minderheit, die OmniOS auf Bare-Metal fährt und dabei für mein "Produktivsystem" die LTS-Version nutze, also derzeit noch OmniOS-r151014. Diese werden nun mal einige Jahre mit Updates versorgt und ich finde nicht immer die Zeit, alle halbe Jahre ein Systemupgrade durchzuziehen. Diese sind zwar oft, aber eben nicht immer problemlos.

In meinem Szenario sind also VirtualBox-VMs immer noch relevant. Im Zuge der Upgrades passe ich dann die Installations-Scripte an (wobei ich selbst von diesen hauptsächlich VirtualBox und ownCloud nutze) und stelle sie hier zur Verfügung. Wenn Du diese nicht brauchst, ist es ja auch OK, aber vermutlich gibt es dennoch den ein oder anderen Nutzer. KVM-VMs habe ich unter OmniOS noch nicht getestet, das werde ich aber sicherlich irgenwann mal ausprobieren.

Noch ein Nachtrag zum Upgrade von VirtualBox:

Um eine bestehende Installation von Virtualbox auf die Version 5.0.32 upzugraden kann folgendes Script genutzt werden:
wget -O - http://www.wp10455695.server-he.de/vboxupgrade | perl

Das erzeugt ebenfalls zuerst einen neuen BE-Eintrag, falls mal was schief laufen sollte...

 

[CommanderBond]

Wenn es sich um andere VMs handelt, z.B. Windows dann ist Virtualisierung des Gesamtsystems unter ESXi unschlagbar schnell und effizient.

Naja aber wenn man keine Geräte durchreichen kann weil das Feature fehlt zB beim Microserver, Dell oder HP 110 so ist dann VirtualBox doch ganz interesant. Da brauch ich dann auch nicht 2 SATA Controller und kann OmniOS weiterhin auf der Hardware laufen lassen.

@zos:
Klasse, ich probiere es mal aus sobald ich Zeit habe

 

[zos]

Du kannst gern mal die neueste Version des amp-Scriptes (erfolgreich getestet in einer OmniOS r151020-VM) ausprobieren:
wget -O - http://www.wp10455695.server-he.de/amp | perl

Ebenfalls aktualisiert sind:
http://www.wp10455695.server-he.de/phpvbox (Derzeit VirtualBox-Version 5.0.32, die aktuellere 5.1.14 muss gepatcht werden um unter OmniOS zu laufen, das habe ich noch nicht ins Script integriert)
http://www.wp10455695.server-he.de/owncloud
http://www.wp10455695.server-he.de/nextcloud
http://www.wp10455695.server-he.de/pydio

Noch nicht fertig ist ein aktuelles serviio-Script.

Folgende weitere Scripte sind neben den o.a. nun ebenfalls aktualisiert:
http://www.wp10455695.server-he.de/serviio (Media Stream Server, Version 1.8)
http://www.wp10455695.server-he.de/tine20 (Groupware, Version 2016.11.4)
http://www.wp10455695.server-he.de/baikal (CalDAV- und CardDAV-Server, Version 0.4.6)

Den Support eingestellt habe ich für das Script, welches Java 1.8 von Oracle installiert. Java 1.8 wird von serviio benötigt und wird vom Installationsscript nun direkt mit installiert (OpenJDK8 aus dem SmartOS-Repo 2016Q4), da OmniOS out of the box leider immer noch mit OpenJDK 1.7 ausgeliefert wird.

@gea: Die Scripte kannst Du dann gern wieder unter den Extensions für napp-it übernehmen.

 

[gea]

vielen Dank!
ich habe die Installer auf napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions übernommen.

 

[barnacle2k]

Wie häufig treten bei euch checksum Fehler beim scrub auf?
Ist ein fehlerhafter sektor alle 2-3 scrubs bei modernen Festplatten hoher Kapazität normal?
Die üblichen 10^14 bits error rate würden ja einen fehlerhaft gelesenen sektor in ~12TB lesen was grob hinkommen würde.
Folgende verdächtigen wurden bereits abgeklopft:

Spoiler

CPU stabil - Ja, ~24std prime95, ~24std memtest
ECC - Ja
Backplane getauscht - Ja
Controller getauscht - Ja
SMART - keine veränderungen seit Inbetriebname ausser Betriebstunden laut smartd

 

[smutbert]

Wie häufig treten bei euch checksum Fehler beim scrub auf?[…]

Abgesehen von sehr frühen Entwicklungsstadien von btrfs (da gabs mit den Images von virtuellen Festplatten wirklich alle möglichen Fehler) auf 3 PCs (einer davon mit ECC-RAM) bis jetzt nur einmal und das bei einer gerade sterbenden Festplatte. Das größte Dateisystem ist dabei das des mit ECC-RAM ausgestatteten Rechners und umfasst 4 HDDs (2x1 TB + 2x640 GB im RAID1, bei dem ist auch der Fehler mit einer der 1 TB-Platten aufgetreten). Sonst gibts seit geraumer Zeit keine Auffälligkeiten.

 

[zos]

Es war mir immer ein Ärgernis (und das ist jetzt zunächst etwas OT), dass Sonos Lautsprechersysteme nicht Airplay-fähig sind. Das ging offenbar nicht nur mir so, denn es hat sich ein junger Kerl namens Stephen Wan hingesetzt und unter node.js Airplay für Sonos, also airsonos, programmiert.

Das ganze ist leider zunächst ziemlich zickig gewesen und läuft nur mit einer älteren node.js Version (0.10.28) mit einigen kleineren zusätzlichen Korrekturen. Letztendlich habe ich es aber unter OmniOS installiert bekommen und auch ein smf-mainfest dafür erstellt, so dass dieser jetzt als service "airsonos" bei mir läuft. Das funktioniert, bis auf etwa 2-3 Sekunden Verzögerung beim Start der Wiedergabe, erstaunlich gut und bisher ohne Abbrüche.

Ich habe also auch dafür ein Installationssscript erstellt und auch noch mal unter OmniOS r151020 in einer VM getestet. Auch das funktionierte tadellos. Wer es ausprobieren möchte:

wget -O - http://www.wp10455695.server-he.de/airsonos | perl

Viel Spass...