[Sammelthread] ZFS Stammtisch

Da wirst Du in den Installationsprozess eingreifen müssen, eine ähnliche Fragestellung fand ich mal in diesem diesem Thread bzgl. lz4-compression bei der rpool-Installation.

EDIT: Soll heissen, wenn Du die /kernel/drv/sd.conf schon vor Anlage des rpools im Installationsprozess mit den "sd-config-list ="-Einträgen versorgst, sollte die Anlage des rpools anschliessend mit der korrekten physical-block-size erfolgen.

Und noch etwas: In Deinem Link ist die Samsung SSD 840 (die habe ich auch im Einsatz) mit einer physical-block-size von 8192 Bytes aufgeführt, also ashift=13...

Sodele, ich hab es mal an meinem Backup-Server getestet - allerdings ist dort nicht die Samsung SSD 840 verbaut, sondern eine Kingston SSDnow 200/30GB. Da ich die Sectorgröße nicht finden kann, hab ich einfach mal 4096 angegeben.

Von der iso gebootet, mit 3 zur CLI und in /kernel/drv/sd.conf eingefügt:
Code:
sd-config-list =
        "ATA     Kingston SS200S3", "physical-block-size:4096",
	"ATA     SAMSUNG HD203WI ", "physical-block-size:4096",
	"ATA     Hitachi HDS5C302", "physical-block-size:4096";
rpoolCustomize noch mit ein paar weiteren Optionen ausgeführt und dann Installation standardgemäß durch laufen lassen. Gefühlsmässig hat die Install etwas länger gedauert, aber keine Meldungen auch nichts in der Log zu finden.
reboot
jetzt kommt gleich auf der Console folgende Meldung:
Code:
WARNING: Disk, '/dev/dsk/c3t0d0s0', has a block alignment that is larger than the pool's alignment

Code:
root@arche:~# iostat -Er | grep -i vendor | sort | uniq
Vendor: ATA      ,Product: KINGSTON SS200S3 ,Revision: 05.1 ,Serial No: xxxxx

SSD wird erkannt.
Code:
root@arche:~# echo ::sd_state | mdb -k | egrep '(^un|_blocksize)'
un 0: ffffff04e92926c0
    un_sys_blocksize = 0x200
    un_tgt_blocksize = 0x200
    un_phy_blocksize = 0x1000
    un_f_tgt_blocksize_is_valid = 0x1
un 1: 0
...
...
Hm, die echte Blocksize ist 4096b, aber rpool wurde

Code:
root@arche:~# zdb | egrep 'ashift| name'
    name: 'rpool'
            ashift: 9
nur mit ashift=9 --> 512b angelegt
Code:
root@arche:~# echo "::walk sd_state | ::grep '.!=0' | ::print struct sd_lun un_s 
d | \
>   ::print struct scsi_device sd_inq | ::print struct scsi_inquiry \
>   inq_vid inq_pid" | mdb -k
inq_vid = [ "ATA     " ]
inq_pid = [ "KINGSTON SS200S3" ]
Auch hier scheint alles i.O.

Wenn ich die Warnung richtig verstehe, könnte der Installer die SSD auf eine Blockgröße von 4096b formatieren, hat rpool trotzdem nur mit einer Blockgröße von 512b angelegt.
Keine Ahnung, ob jetzt an der Kingston SSD liegt oder dass die SSD schon eine Solaris2 Partition hatte oder eventl. zwingt der Installer rpool mit ashift=9 anzulegen.

Also alles wieder zurück auf Anfang.:fresse2:

------------------------------------------------
Änderung:
Bin wieder am Anfang.
Sobald die SSD vom rpool in der sd.conf eingetragen ist, kommt beim Neustart obige Warnung.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bin wieder am Anfang.
Sobald die SSD vom rpool in der sd.conf eingetragen ist, kommt beim Neustart obige Warnung.

In der sd.conf sind nach meinem Verständnis lediglich die Platten einzutragen, die bei ihrer physical-block-size "lügen", also zB 512 Byte melden statt 4096 Byte.

Deine Kingston SSD 30GB ist nicht in der Liste auf der illumos-Seite enthalten (wobei diese nicht unbedingt vollständig ist), mglw meldet diese ja korrekte Werte und es kommt aus diesem Grunde zu der Warnung, vielleicht weil die gemeldete block-size (die aus sd.conf) dann größer als die physische wäre (sonst ist es umgekehrt). Trotzdem ist mir ist nicht 100% klar, wie die Warnung jetzt zu interpretieren ist, so dass mE nur ein weiterer Test mit der Samsung SSD 840 hier Klarheit bringen kann, da Du bei dieser Platte sicher weißt, welche physical-block-size diese meldet und welche sie tatsächlich hat.
 
Zuletzt bearbeitet:
In der sd.conf sind nach meinem Verständnis lediglich die Platten einzutragen, die bei ihrer physical-block-size "lügen", also zB 512 Byte melden statt 4096 Byte.
Mag sein, dass du hier recht hast, auf der anderen Seite ist mein Datengrab auf der Samsung SSD840 installiert und da ist ashift=9. Deshalb bin ich jetzt davon ausgegangen, dass wenn in der sd.conf die Block-Size vorgegeben wird, der Installer Dies auch so umsetzt - also ashift=12 beim rpool macht.

Deine Kingston SSD 30GB ist nicht in der Liste auf der illumos-Seite enthalten (wobei diese nicht unbedingt vollständig ist), mglw meldet diese ja korrekte Werte und es kommt aus diesem Grunde zu der Warnung, vielleicht weil die gemeldete block-size (die aus sd.conf) dann größer als die physische wäre (sonst ist es umgekehrt).
Richtig die Kingston steht nicht in der Liste, sie meldet aber 4k physische block-size
Code:
root@arche:~# echo ::sd_state | mdb -k | egrep '(^un|_blocksize)'
un 0: ffffff04e92926c0
    un_sys_blocksize = 0x200
    un_tgt_blocksize = 0x200
    un_phy_blocksize = 0x1000 <<-------- 4096b
    un_f_tgt_blocksize_is_valid = 0x1
un 1: 0
...
...
Trotzdem ist mir ist nicht 100% klar, wie die Warnung jetzt zu interpretieren ist, so dass mE nur ein weiterer Test mit der Samsung SSD 840 hier Klarheit bringen kann, da Du bei dieser Platte sicher weißt, welche physical-block-size diese meldet und welche sie tatsächlich hat.
Ich auch nicht, vor allem wenn ich die Kingston aus der sd.conf wieder raus nehme, kommt nach einem Neustart diese Warnung nicht mehr.
LOL so ungefähr - nach dem Motto Versuch macht klug.
 
Mag sein, dass du hier recht hast, auf der anderen Seite ist mein Datengrab auf der Samsung SSD840 installiert und da ist ashift=9. Deshalb bin ich jetzt davon ausgegangen, dass wenn in der sd.conf die Block-Size vorgegeben wird, der Installer Dies auch so umsetzt - also ashift=12 beim rpool macht..

In diesem Beitrag steht noch, nachdem die sd.conf editiert und mit "update_drv -vf sd" im laufenden Kernel aktualisiert wurde, sei noch Folgendes zu tun:

(...) Unfortunately this new setting will not take effect as long as the current disk is attached so we must force it to unattach and reattach: (...)
The trick here is to unconfigure the device using ‘cfgadm’ and to then reconfigure it. This will force the sd driver to re-attach the device with the new physical-block-size. (...)

Ich gehe zwar davon aus, dass Du das schon alles gelesen und so durchgeführt hast, nur sei es der Vollständigkeit halber nochmal erwähnt.
 
In diesem Beitrag steht noch, nachdem die sd.conf editiert und mit "update_drv -vf sd" im laufenden Kernel aktualisiert wurde, sei noch Folgendes zu tun:

(...) Unfortunately this new setting will not take effect as long as the current disk is attached so we must force it to unattach and reattach: (...)
The trick here is to unconfigure the device using ‘cfgadm’ and to then reconfigure it. This will force the sd driver to re-attach the device with the new physical-block-size. (...)

Ich gehe zwar davon aus, dass Du das schon alles gelesen und so durchgeführt hast, nur sei es der Vollständigkeit halber nochmal erwähnt.

Nein, kannte ich nicht.
Leider bin ich des Englischen nicht so mächtig, daher möchte ich dich bitten mal diese pdf hier Seite 12 und dieses Video ab 11.min. anzusehen. Wenn ich es richtig verstehe gibts bei 4k Schwierigkeiten bei RaidZ-Pools und bei rpool (grub).
Kannste du mir da mal bitte weiterhelfen?

Ich hab die Seite jetzt mal durchgelesen.
Verstehe ich es richtig, dass Georg Wilson die Änderung auf ashift=12 im laufenden Betrieb bei einem rpool gemacht hat und Openindiana nicht mehr neu installiert werden musste.
 
Zuletzt bearbeitet:
Nein, kannte ich nicht.
Leider bin ich des Englischen nicht so mächtig, daher möchte ich dich bitten mal diese pdf hier Seite 12 und dieses Video ab 11.min. anzusehen. Wenn ich es richtig verstehe gibts bei 4k Schwierigkeiten bei RaidZ-Pools und bei rpool (grub).
Kannste du mir da mal bitte weiterhelfen?

Ich hab die Seite jetzt mal durchgelesen.
Verstehe ich es richtig, dass Georg Wilson die Änderung auf ashift=12 im laufenden Betrieb bei einem rpool gemacht hat und Openindiana nicht mehr neu installiert werden musste.

Nein, das hat er mE nicht gemacht (siehe auch seine Antwort auf einen Kommentar in seinem Artikel: "You can override the setting in sd.conf but it does not affect existing pools"). So wie ich es interpretiere, hat er eine OpenIndiana Live-DVD/ISO verwendet, folglich war zu diesem Zeitpunkt noch kein rpool eingerichtet. Da sein Artikel auch aktueller als sein Auftritt beim ZFS-Day ist, nehme ich an, dass die Einrichtung eines rpool mit ashift=12 eigentlich klappen müsste, zumindest suggerieren das seine Screenshots.

Zu RaidZ und 4k-Blocks:
Hier kommt es lt Wilson auf die Record-Größen an die geschrieben werden. Sind diese gross (so wie bei Film-, Bild-, Musikdateien) sollte ein RaidZ-Pool mit 4k-Platten OK sein. Sind diese hingegen meist klein (<= 8k) so wird viel Platz verschwendet (auch die Parity-Daten werden dann ja in 4k-Blöcke geschrieben, hier ein Beispiel wieviel Platz dabei drauf gehen kann). Es kommt also ganz auf die hauptsächliche Verwendung des Pools an.
 
Zuletzt bearbeitet:
Zu RaidZ und 4k-Blocks:
Hier kommt es lt Wilson auf die Record-Größen an die geschrieben werden. Sind diese gross (so wie bei Film-, Bild-, Musikdateien) sollte ein RaidZ-Pool mit 4k-Platten OK sein. Sind diese hingegen meist klein (<= 8k) so wird viel Platz verschwendet (auch die Parity-Daten werden dann ja in 4k-Blöcke geschrieben, hier ein Beispiel wieviel Platz dabei drauf gehen kann). Es kommt also ganz auf die hauptsächliche Verwendung des Pools an.


Ich dachte dieser Overheat kommt nur bei raidz2 vor.
Hier ein paar links zur Thematik:

inefficient use of space observed when using raidz2 with ashift=12

RAIDZ2 space efficiency problem

Auch interessant KLICK

PS: Es gibt sogar zwei offizzielle Bug-Tickets bei illumos zu dieser "Platzverschwendung", aber wie es aussieht kümmert sich keiner darum. :/
Ticket 1
Ticket 2
 
Zuletzt bearbeitet:
Meine Pools sind alle mit ashift 12 gesetzt. Performance ist aus meiner Sicht gut bis sehr gut. Vielleicht habe ich aber auch andere Ansprüche.
Ich nutze die beiden Büchsen nur für Video + Foto Datengrab ( arbeite auch nativ drauf ) und via Replication sichere ich den Poolbestand auf eine andere Büchse. Bissel NFS/ iSCSI für Apple ( Final Cut ) uns als Datastore für Esxi.

Kennt einer das hier ?
MikroTik RouterBOARD RB14e, Adapter card, 4x miniPCI-e - varia-store.com

Dazu zwei mSSD als Cache....hat da jemand Erfahrungen mit ?

-xymos.
 
Für was soll dieses Adapterboard genau herhalten?
 
Danke, dass du meiner Bitte nachgekommen bist.

Nein, das hat er mE nicht gemacht (siehe auch seine Antwort auf einen Kommentar in seinem Artikel: "You can override the setting in sd.conf but it does not affect existing pools"). So wie ich es interpretiere, hat er eine OpenIndiana Live-DVD/ISO verwendet, folglich war zu diesem Zeitpunkt noch kein rpool eingerichtet. Da sein Artikel auch aktueller als sein Auftritt beim ZFS-Day ist, nehme ich an, dass die Einrichtung eines rpool mit ashift=12 eigentlich klappen müsste, zumindest suggerieren das seine Screenshots.

Du hast Recht - hier steht ja: 'Once the install is started you can check that the pool has the correct ashift property:' :(

Mit Schwierigkeiten, Wilson nennt es Nachteile, meinte ich auch wie geschrieben die Seite 12 der pdf:
Drawbacks of 4K and ZFS
● Reduced compression ratio
.....○ Blocks less than 4K mean 0% compression
.....○ 8K block can only achieve 50% compression
● Migrating drives from 512B to 4K
● Inefficient metadata allocation
.....○ Some metadata is allocated in 4K chunks and will no
longer get compressed
● Improper accounting of compressed sizes in datasets
● RAID-Z and 4k -- not recommended
● Configuring root pools to use 4K
.....○ Grub support?
● Fewer uberblocks
Zu RaidZ und 4k-Blocks:
Hier kommt es lt Wilson auf die Record-Größen an die geschrieben werden. Sind diese gross (so wie bei Film-, Bild-, Musikdateien) sollte ein RaidZ-Pool mit 4k-Platten OK sein. Sind diese hingegen meist klein (<= 8k) so wird viel Platz verschwendet (auch die Parity-Daten werden dann ja in 4k-Blöcke geschrieben, hier ein Beispiel wieviel Platz dabei drauf gehen kann). Es kommt also ganz auf die hauptsächliche Verwendung des Pools an.

In deinem Link > 50% Verlust bzw. zusätzlicher Bedarf ist schon arg heftig.

Wir reden ja die ganze Zeit davon, den rpool bei der Installation gleich auf 4k oder 8k 'hin zu biegen' - nicht vom Datenpool. Beim Datenpool ist es ja relativ einfach. sd.conf bearbeiten, "update_drv -vf sd" in der CLI eingeben oder ein reboot, pool anlegen, fertisch.

Wenn ich mir aber so die Dateigrößen, welche auf rpool liegen anschaue, macht es doch IMHO überhaupt keinen Sinn rpool mit ashift=12 oder gar 13 anzulegen.
Eure Meinung zu rpool?
 
Ich dachte dieser Overheat kommt nur bei raidz2 vor.
Hier ein paar links zur Thematik:

inefficient use of space observed when using raidz2 with ashift=12

RAIDZ2 space efficiency problem

Auch interessant KLICK

PS: Es gibt sogar zwei offizzielle Bug-Tickets bei illumos zu dieser "Platzverschwendung", aber wie es aussieht kümmert sich keiner darum. :/
Ticket 1
Ticket 2

WOW, wo ihr immer die interessanten Seiten so findet. ganzneidisch.

Der Link vom Hardforum enthält noch einen weiteren sehr Interessanten ZFS 4k aligned space overhead

Dadurch ändert sich die optimale Anzahl an Festplatten für:
RAIDZ1
mit ashift=9 (512b): 3,5,9 HDD
mit ashift=12 (4k): 2,3,5,9,17 HDD

RAIDZ2
mit ashift=9 (512b): 4,6,10 HDD
mit ashift=12 (4k): 3,6,18 HDD
 
Tausend Seiten, Tausend Theorien

allgemeiner Konsens ist:

- 4k Platten haben Vorteile bei großen Platten
Der Nachteil, dass bei Minidateien Dateigrößen immer n*4k ist ist unerheblich da dies nicht die "Normaldateii" ist und Platz eh im Überfluss da ist (Ein Byte speichern=4k Datei)

Ein manuelles Setzen des ashift Parameters bei ZFS macht nur Sinn falls
- die Platte lügt (Erste Generation 4k Platten)
- man ein späteres Replace mit 4k Platten erlauben möchte (mirror oder Raid-Z)

Für rpool kann ich wenig Sinn erkennen, ashift manuell zu setzen. Bei Mirror gäbe es das "Replace-Problem". Ist aber ganz selten ein echtes Problem.

ZFS schreibt Daten in Datenblöcken. Diese Datenblöcke sollten auch als Raid-Stripe immer n*4k groß sein damit beim Speichern kein Verschnitt bleibt (z.B. Datenblock=3k, Blockgröße=4k: 25% Verschnitt). Das ist dann der Fall, wenn man bei Raid-Z(1-3) 1,2,4,8,16,32,64,128 Datenplatten per vdev einsetzt. Für Raid-Z muss man die Paritätsplatten dazuzählen (1 bei Z1, 2 bei Z2 und 3 bei Z3) um die optimale Anzahl der Platten per vdev zu haben.
 
Zuletzt bearbeitet:
Wenn ich mir aber so die Dateigrößen, welche auf rpool liegen anschaue, macht es doch IMHO überhaupt keinen Sinn rpool mit ashift=12 oder gar 13 anzulegen.
Eure Meinung zu rpool?

allgemeiner Konsens ist:

- 4k Platten haben Vorteile bei großen Platten
Der Nachteil, dass bei Minidateien Dateigrößen immer n*4k ist ist unerheblich da dies nicht die "Normaldateii" ist und Platz eh im Überfluss da ist (Ein Byte speichern=4k Datei)

Ein manuelles Setzen des ashift Parameters bei ZFS macht nur Sinn falls
- die Platte lügt (Erste Generation 4k Platten)
- man ein späteres Replace mit 4k Platten erlauben möchte (mirror oder Raid-Z)

Für rpool kann ich wenig Sinn erkennen, ashift manuell zu setzen. Bei Mirror gäbe es das "Replace-Problem". Ist aber ganz selten ein echtes Problem.

Was mir noch nicht ganz klar ist:
Heisst dass denn nun auch, dass (sofern die Platte nicht lügt), bei der Anlage des rpools während der Installation automatisch die richtige physical-block-size gewählt wird oder immer ashift=9 (Was anderes als ashift=9 habe ich beim rpool nämlich noch nicht gesehen)?

Aber ob sinnig oder unsinnig, ich für meinen Teil empfinde es als "sauberer", wenn die wahre physical-block-size zum Zuge kommt, egal ob rpool oder nicht.
 
Dadurch ändert sich die optimale Anzahl an Festplatten für:
RAIDZ1
mit ashift=9 (512b): 3,5,9 HDD
mit ashift=12 (4k): 2,3,5,9,17 HDD

RAIDZ2
mit ashift=9 (512b): 4,6,10 HDD
mit ashift=12 (4k): 3,6,18 HDD


Die fett markierten sind 2- bzw. 3-Way-Mirrors. Und mir ist nicht klar, warum bei Z2 4 und 10 wegfallen sollen? Die "Rechnung" im Link leuchtet mir nicht ein, und wenn man diesen "Beweis" für 512B-Platten durchführt, kommt man auch auf nen krummen Wert.


@zos: Das klang auch am Ende des Videos an, wenn ich mich recht erinnere. Stand damals aber ungelöst.
 
Was mir noch nicht ganz klar ist:
Heisst dass denn nun auch, dass (sofern die Platte nicht lügt), bei der Anlage des rpools während der Installation automatisch die richtige physical-block-size gewählt wird oder immer ashift=9 (Was anderes als ashift=9 habe ich beim rpool nämlich noch nicht gesehen)?

Wenn die Platte 4k physical sector meldet, macht ZFS ashift=12 automatisch.
Bei kleineren Platten wie man sie für rpool nimmt, sind aber 512B physical sector üblich.
 
Wenn die Platte 4k physical sector meldet, macht ZFS ashift=12 automatisch.
Bei kleineren Platten wie man sie für rpool nimmt, sind aber 512B physical sector üblich.

Wir reden hier ja die ganze Zeit ausschließlich vom rpool und nicht vom Datenpool.
Bisher hat jeder Installer den rpool auf ashift=9 gesetzt, egal ob es eine SSD mit 30 GB oder 120 GB war. Auch eine HDD mit 500GB wurde auf ashift=9 gesetzt.
512b ist eigentlich bei der Dateiengröße auch das Sinnvollere.
Daher vermute ich, dass Omnios Dies bewusst so will.

------------------------------------------------------
Was ganz anderes.
Ich möchte gerne mein doku-wiki aus einer eigens dafür gemachte VM raus haben und auf meinem Omnios-Server laufen lassen. Auch aus dem alten XAMPP Projekt läuft noch eine kleine MySql Datenbank. XAMPP läßt sich so ja nicht mehr installieren. Dafür gibts ja jetzt den Webstack.

Hat jemand von euch 'ampo' oder 'amp04' installiert?

Nach der Installation startete ich ./ampo02.sh welches das Perl-Script '/opt/local/bin/mysql_secure_installation' ausführt. Hier bekomme ich folgende Fehlermeldung:
Code:
Can't find a 'mysql' client in PATH or ./bin
Cleaning up...
Warning: Could not unlink .my.cnf.5020: No such file or directory
Warning: Could not unlink .mysql.5020: No such file or directory

Eine my.conf liegt bei mir unter /opt/local/my.conf

Wenn ich mysql mit napp-it konfigurieren will, kommt folgende Fehlermeldung:
Code:
Es ist ein Fehler aufgetreten. Bitte versuchen Sie es nochmal oder starten den Rechner neu oder verständigen Sie den Administrator .
edit 2806 : source file not found
/etc/mysql/my.cnf

$PATH zeigt auch hier nicht darauf:
Code:
root@ripley:~# echo $PATH
/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin

Was mach ich denn jetzt schon wieder falsch?? :fresse2:
 
$PATH zeigt auch hier nicht darauf:
Code:
root@ripley:~# echo $PATH
/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin

Was mach ich denn jetzt schon wieder falsch?? :fresse2:

Setze Deinen PATH mal bitte neu:
export PATH=/opt/local/bin:/opt/local/sbin:/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin

Danach starte ./ampo2.sh nochmal. Es sollte dann funktionieren.

EDIT/PS.: Am besten trägst Du den oa "export PATH..." in die .profile-Datei Deines home-Verzeichnisses ein
 
Zuletzt bearbeitet:
Setze Deinen PATH mal bitte neu:
export PATH=/opt/local/bin:/opt/local/sbin:/usr/gnu/bin:/usr/bin:/usr/sbin:/sbin

Danach starte ./ampo2.sh nochmal. Es sollte dann funktionieren.

EDIT/PS.: Am besten trägst Du den oa "export PATH..." in die .profile-Datei Deines home-Verzeichnisses ein

YEP, funktioniert. ampo2.sh läuft jetzt.
Danke.

Eine my.conf liegt bei mir unter /opt/local/my.conf

Wenn ich mysql mit napp-it konfigurieren will, kommt folgende Fehlermeldung:
Code:
Es ist ein Fehler aufgetreten. Bitte versuchen Sie es nochmal oder starten den Rechner neu oder verständigen Sie den Administrator .
edit 2806 : source file not found
/etc/mysql/my.cnf

Dieser Fehler kommt trotzdem in napp-it.
Wo gehört jetzt die my.conf hin? Unter /opt/local/my.conf oder unter /etc/mysql/my.cnf??

Ist das ein Bug in napp-it, so wie der falsche Link zu myphpadmin?
 
Leute, Leute. Entweder benutzt ihr vorgekaute Sachen - und _nur_ die - oder ihr habt Ahnung, was ihr da überhaupt treibt. Dickste Kisten hinstellen und die Administration ist dann Malen nach Zahlen. Sorry, wenn ich das so sage, aber Kinkerlitzchen wie $PATH und wie man generell Serversoftware betreibt, sollte man schon draufhaben.

Da wird napp-it wohl von einer falschen Installationsbasis ausgehen. Guck doch mal in den Source.

Code:
$ grep -r my.cnf .
./web-gui/data_0.9b3/napp-it/zfsos/02_services/05_MySQL/02_config/action.pl:  $r=&edit("/etc/mysql/my.cnf");

Aha, die einzige Stelle, wo my.cnf vorkommt, ist da. Gucken wir uns mal etwas um:

Code:
$ more web-gui/data_0.9b3/napp-it/zfsos/02_services/05_MySQL/05_start/action.pl
[...]
     $r=&exe("svcadm enable -rst svc:/application/database/mysql");                  # enable smb

     $r=&exe("svcs | grep svc:/application/database/mysql");                          # show status
[...]

Aha, der startet mysql einfach übers System, hat aber für die "Konfig", was einfach nur ein Texteditieren ist, einen hartkodierten Pfad drin. Ist doch ein sonnenklares Problem. Du kannst jetzt entweder einfach die Datei von Hand bearbeiten oder den Pfad in napp-it ändern, wobei das beim nächsten Update wahrscheinlich wieder weg ist. Da erlebst du gleich hautnah, warum hardcoden Müll ist. Ist doch prima. :)

Sachen wie napp-it sind keine saubere Software, die man einfach in ein wildgewachsenes System integrieren kann. Sowas läuft am besten als Appliance[1].

[1] Appliance: Zauberwort, was nichts weiter bedeutet, dass der Autor keinen Bock auf Sauberkeit hat und deswegen nur mit seinem eigenen Ökosystem klarkommt, welches er dir netterweise gleich komplett mitschickt.
 
Zuletzt bearbeitet:
Leute, Leute. Entweder benutzt ihr vorgekaute Sachen - und _nur_ die - oder ihr habt Ahnung, was ihr da überhaupt treibt. Dickste Kisten hinstellen und die Administration ist dann Malen nach Zahlen. Sorry, wenn ich das so sage, aber Kinkerlitzchen wie $PATH und wie man generell Serversoftware betreibt, sollte man schon draufhaben.

Du hast Recht - ja du hast ja so was von Recht.

Vermutlich bist du schon als Nerd auf die Welt gekommen und hast nichts Neues mehr lernen brauchen.

Aha, der startet mysql einfach übers System, hat aber für die "Konfig", was einfach nur ein Texteditieren ist, einen hartkodierten Pfad drin. Ist doch ein sonnenklares Problem. Du kannst jetzt entweder einfach die Datei von Hand bearbeiten oder den Pfad in napp-it ändern, wobei das beim nächsten Update wahrscheinlich wieder weg ist. Da erlebst du gleich hautnah, warum hardcoden Müll ist. Ist doch prima. :)

Kannst du dir vielleicht vorstellen, dass ich den Fehler erst einmal bei mir suche und nicht in napp-it?

Schade ist, dass solche Bemerkungen, wie die Deinige, es Nichtprofis verleiten hier im Forum überhaupt noch nach zu fragen.
 
Verbitterter Sysadmin Ende 30 mit mickrigem Gehalt sucht Bestätigung/Opfern in Foren, da er überall anders ignoriert wird :fresse:
 
YEP, funktioniert. ampo2.sh läuft jetzt.
Danke.



Dieser Fehler kommt trotzdem in napp-it.
Wo gehört jetzt die my.conf hin? Unter /opt/local/my.conf oder unter /etc/mysql/my.cnf??

Ist das ein Bug in napp-it, so wie der falsche Link zu myphpadmin?

Gern geschehen.

Die mysql-Installation von napp-it erfolgt seit Mitte letzten Jahres nicht mehr über das veraltete XAMPP für Solaris, sondern seit effemmess das ampo-Script erstellt hat (und über napp-it zum download bereit gestellt wurde) über die Joyent/SmartOS-Repo's. Im XAMPP wurde die my.cnf unter /etc/mysql abgelegt, SmartOS-Pakete werden aber eben unter /opt/local installiert ergo auch die my.cnf.

Diese Anpassung ist bei napp-it an dieser Stelle eben noch nicht erfolgt.

Man kann sich jetzt natürlich fragen, ob es saubere, oder provokanter formuliert, fehlerfreie Software überhaupt gibt. Fakt ist aber, dass es ohne napp-it und gea's unermüdlichem Support für viele Leser hier wesentlich schwieriger wäre mit ZFS und Solaris "warm zu werden" (selbstverständlich gibt es auch viele andere helfende User hier, deren Unterstützung soll das nicht schmälern).

Es ist eben wie so oft im Leben: Für den einen ist ein auftretendes Hindernis das schwierigste Probleme für den anderen eine Trivialität. Aber das kann in einer anderen Situation eben auch genau umgekehrt gelten.

Ich für meinen Teil habe hier sehr viel gelernt und bisher habe ich es immer außerordentlich geschätzt, dass es hier nicht so zugeht wie in so manchem heise-Forum. Es würde mich freuen, wenn das so bleibt.
 
Muss TCM da leider recht geben, viele Leute hier posten über Probleme die sie nicht hätten wenn Sie sich zuvor einfach mal etwas mit den Basics beschäftigt hätten. Da wird dann im Jahr tagelang herumgefuscht und gedoktert ohne überhaupt zu verstehen was man da macht. In der selben Zeit hätte man aber auch sich einfach mal entsprechendes Wissen anlegen können und würde dann in Zukunft viel Zeit sparen.

Für jeden der sich hier angesprochen fühlt habe hier einen Youtube Channel der für *NIX-Neulinge sehr interessant sein sollte, Darren und Shannon erklären das echt gut, hätte ich das vor knapp 10 Jahren auch gehabt wäre mein Einsteig wohl viel leichter gewesen.
Youtube - Hak5
Youtube - Hak5 - Suche "HakTip"

Ich komme in letzter Zeit recht wenig zu posten da meine Hände beim Lesen der meisten Posts hier an der Stirn festkleben. facepalm2dmut.gif :fresse: ;)

Zum Beispiel die ashift Diskussion hatten wir schon so oft und sie wurde schon so oft wo anders breit getreten, warum dann hier wieder soviel gepostet werden muss erschließt sich mir nicht. Es gibt schon seit Jahren nur noch 4K-Laufwerke, die meisten davon mit 512B-Emulation. ashift=12 ist also quasi ab allen Festplatten von 2011 und aufwärts, teilweise schon früher, die richtige Wahl und auf SSDs immer richtig.

Auch die optimale Aufteilung von Festplatten in unterschiedlichen Raid-Z Leveln und ashift hatten wir bestimmt vor einem Jahr oder länger schon mehrfach.

Oder zuvor als mal wieder das Thema Encryption kam wo irgendwelche Leute mit ihren Vermutung kamen dass native ZFS-Crypto ja schneller als LUKS/geli sei weil es ja der "kompliziertere Aufbau" sei oder so ähnlich. Das verschlüsselte Blockdevices unter ZFS zwar in der Praxis enorm schneller und ressourcensparender sind als die native Solaris-ZFS-Crypto (performancetechnisch der letzte Scheiß) haben die Herren wohl noch nicht bemerkt.

Und was es bringen soll sich für ein bisschen mehr Performance für ein paar GB an Daten auf rpool die sowieso quasi nur beim Systemstart gelesen werden die suboptimale Sektornutzung zu verbesseren verstehe ich noch weniger. Da wird dann stundenlang recherchiert und geschrieben und eine völlig unwichtige Sache ohne Relevanz zu verbessern. OCD?

Eine besondere Perle findet sich aktuell im Server/Workstation Profibereich wo anscheinend gerade das neue Amazon/Facebook/Ebay 3.0 geboren wird. :fresse:

Du hast Recht - ja du hast ja so was von Recht.

Vermutlich bist du schon als Nerd auf die Welt gekommen und hast nichts Neues mehr lernen brauchen.
Informiere dich doch mal bitte wer heutzutage alles als Nerd gilt. Selbst die Teeny-Mädchen die außer Smartphone und Facebook nichts anderes kennen denken sie sind jetzt "Nerds" weil sie mal Farmville gespielt.
panel-28064707-image-334ce322b37a9be0-320.png
Was bist du dann? Uber-Nerd? :fresse:

Schade ist, dass solche Bemerkungen, wie die Deinige, es Nichtprofis verleiten hier im Forum überhaupt noch nach zu fragen.
Haha, der war gut. Es fragen doch hier zu 90% Nicht-Profis, wer sich da nicht mehr traut ist einfach ein Angsthase. :p

Verbitterter Sysadmin Ende 30 mit mickrigem Gehalt sucht Bestätigung/Opfern in Foren, da er überall anders ignoriert wird :fresse:
facepalm.gif

TCM hat einfach nur etwas mit offenen Worten angesprochen, kein Grund ihm gleich an die Gurgel zu gehen.
 
Zuletzt bearbeitet:
Haha, der war gut. Es fragen doch hier zu 90% Nicht-Profis, wer sich da nicht mehr traut ist einfach ein Angsthase. :p

Es ist eine Frage des Umgangstons. Es ist schlimm, wenn man sich trauen muss um in einem Forum das zu 90% aus Nicht-Profis bestehen soll (was ich angesichts der vielen kompetenten Antworten bezweifle) eine Frage zu stellen, selbst wenn diese vermeintlich banal ist oder bereits vor Jahren als beantwortet gilt. Man kann ja einfach sein Wissen teilen oder die Frage ignorieren, eine frühere Diskussion verlinken oder höflich darauf hinweisen, dass es sich um eine ganz einfache Grundlagenfrage handelt.

Als Entwickler sind es dann ja gerade diese Anfänger-Fragen, die helfen eine Software oder Anleitung zu verbessern oder Fehler zu beheben - zumal wenn es sich wie hier um Zusatz-Software handelt, die Leute aus diesem Forum kostenlos und in ihrer Freizeit bereitstellen, um anderen sehr komplexe Installationen wie Owncloud oder Mediatomb zu ermöglichen die weit über die Funktionen einer Storage-Appliance hinausgehen.
 
Zuletzt bearbeitet:
Es ist eine Frage des Umgangstons.
+1

Da ich keine Angst habe hier eine Noob Frage:
Wie stellt man die An- und Auszeiten bei Napp-it ein? Ich check das nicht so ganz.
Bsp.: Ich möchte gerne das der Server um 9:00 Startet und um 23:00 Uhr runter fährt. Wie müsste ich das in der Powerconf einstellen und welche Parameter müsste unter "Behavior" ("Shutdown" ?) stehen?
Und wie aktiviere ich WoL auf den NIC's ?

Gruß
 
Zuletzt bearbeitet:
Das Herunterfahren geht mit "other job" und "init 5" noch recht einfach
Bei Aufwachen mit WoL wäre ich skeptisch.

Ich würde es manuell mit IPMI machen (sofern vorhanden) oder einfach eine Zeitschaltuhr einsetzen und 15 min vor dem Ausschalten den Rechner per other job herunterfahren.
 
@TCM und @GraphikTreiber

Ich schätze eure Beiträge hier und in anderen Themen sehr; sie zeugen von viel Sachverstand und -.wissen.

verleiten angst

Mehr gibts hier nicht mehr zu sagen/schreiben.

Info:
I found stability problems when using e1000 on a default OmniOS VM under ESXi 5.5
It works either when using the VMXnet3 vnic or when adding the following lines to /kernel/drv/e1000g.conf (reboot required)

#Disable TCP segmentation offload and LSO (napp-it all-in-one)
tx_hcksum_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
lso_enable=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;

Maybe similar to this problem:
VMware KB: Possible data corruption after a Windows 2012 virtual machine network transfer

If vnic problem remains:
Stay at ESXi 5.1 or use a physical nic with pass-through for external transfers in addition to a vnic for internal traffic.


read Cyber Explorer: Improving VM to VM network throughput on an ESXi platform
and disable LSO with command:
ndd -set /dev/ip ip_lso_outbound 0

and http://www.vmware.com/pdf/Perf Best Practices vSphere5.5.pdf

@gea,

Ist diese Problematik noch aktuell?
Und vor allem wie macht es sich bemerkbar und ist in den log-files was zu sehen?
 
hallo zusammen,

ich habe mein system leider geupdatet und nun funktioniert mein zfs nicht mehr. ich finde aber irgendwie die lösung nicht im netz. die freigaben
sind nicht mehr zu sehen und die daten auch nicht...

ubuntu linux 13.10
Code:
Linux david-linux 3.11.0-19-generic #33-Ubuntu SMP Tue Mar 11 18:48:34 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
david@david-linux:~$ zpool status
Unable to open /dev/zfs: Permission denied.
Unable to open /dev/zfs: Keine Berechtigung.
david@david-linux:~$ sudo su
[sudo] password for david:
root@david-linux:/home/david# zpool status
  pool: drei_tb
 state: ONLINE
  scan: scrub canceled on Fri Jan  3 00:32:55 2014
config:

        NAME                                        STATE     READ WRITE CKSUM
        drei_tb                                     ONLINE       0     0     0
          ata-WDC_WD30EZRX-00DC0XX_WD-WMC1T2XXXXX3  ONLINE       0     0     0

errors: No known data errors
root@david-linux:/home/david# zfs get mountpoint
NAME            PROPERTY    VALUE         SOURCE
drei_tb         mountpoint  /t3st         local
drei_tb/frei    mountpoint  /t3st/frei    [b]inherited from drei_tb[/b]
drei_tb/fxback  mountpoint  /t3st/fxback  inherited from drei_tb
drei_tb/musik   mountpoint  /t3st/musik   inherited from drei_tb

möglichweise habt ihr ja eine idee.
vielen dank,
david
 
@gea,

Ist diese Problematik noch aktuell?
Und vor allem wie macht es sich bemerkbar und ist in den log-files was zu sehen?

Mit 5.5 und e1000 gabs extrem schlechte Performance und Stabilität bis hin zum Einfrieren.
Ich hatte aber noch nicht die Zeit um das neue 5.5U1 zu testen (samt Update auf die darin enthaltenen VMware tools)
 
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