LichtiF
Enthusiast
1 GB pro TB ist die generelle Empfehlung für ZFS
Probleme mit Pool import
Hallo,
es gab einen Pool X mit 2 Raidz1 vdevs(je 5 Platten). Durch div. Spielereien mit dem "Power Management" habe ich es geschafft diesen Pool zu zerstören. Zpool status meldete 3 Platten sind nicht verfügbar ... was aber nicht weiter schlimm ist, zumal das ganze auf einem Testsystem passierte.
Bei der Gelegenheit dachte ich mir: Was kann man denn mit einem kaputten Pool alles machen bzw. kriegt man diesen wieder zum spielen.
Leider habe ich mir nicht alle Schritte notiert ... welche zu folgenden Zustand führten:
Pool X ist wieder Online - allerdings bekam ich bei "zpool import" keine Ausgabe mehr - nur noch ein newline.
nach "zpool destroy X":
zpool status - nur noch rpool - bei zpool import bekomme ich jetzt den Pool X angezeigt, allerdings mit diversen Fehlern, import ist auch nicht möglich.
ein zpool create Bla - mit den Platten, von der Ausgabe von "zpool import", ging nicht aber mit -f hat es dann geklappt.
Ich dachte nach "zpool destroy Bla" ist alles wieder OK .... bei zpool import bekomme ich immer noch den Pool X angezeigt, mit Fehlern, import ist auch nicht möglich.
Was kann ich machen um den 'Pool X' loszuwerden?
Woher holt sich OmniOs die Infos für die Pools eigentlich?
Da ich so zu keinem Ergebnis kam versuchte ich die Platten zu formatieren. Was ich aber gleich bei der 1. Platte wieder abgebrochen habe obwohl da stand 'nicht abbrechen'.
Nach einem Reboot bekomme ich jetzt Meldungen vom fmd:
DISK-8000-4Q
fmadm repair ... - brachte bei
fmadm faulty - keine Ausgabe mehr
allerdings bleibt mir weiterhin der Zugriff auf die Platte verwehrt - format -e endet nach einer gewissen Zeit mit einer Fehlermeldung und
der fmd meldet sich wieder mit selbigen Fehler.
Wie bekomme ich die Platten wieder in einen Zustand so das OmniOS sie wieder verwenden kann?
Wie bekomme ich den fmd wieder sauber - abschalten ist ja auch keine Lösung(hat auch nichts gebracht - kein Zugriff auf die Platte)?
Kann leider zur Zeit nicht die genauen Fehlermeldungen posten - da ich testweise eine Platte mit LSI Config Utility formatiere und das dauert....
Hallo,
es gab einen Pool X mit 2 Raidz1 vdevs(je 5 Platten). Durch div. Spielereien mit dem "Power Management" habe ich es geschafft diesen Pool zu zerstören. Zpool status meldete 3 Platten sind nicht verfügbar ... was aber nicht weiter schlimm ist, zumal das ganze auf einem Testsystem passierte.
Bei der Gelegenheit dachte ich mir: Was kann man denn mit einem kaputten Pool alles machen bzw. kriegt man diesen wieder zum spielen.
Leider habe ich mir nicht alle Schritte notiert ... welche zu folgenden Zustand führten:
Pool X ist wieder Online - allerdings bekam ich bei "zpool import" keine Ausgabe mehr - nur noch ein newline.
nach "zpool destroy X":
zpool status - nur noch rpool - bei zpool import bekomme ich jetzt den Pool X angezeigt, allerdings mit diversen Fehlern, import ist auch nicht möglich.
ein zpool create Bla - mit den Platten, von der Ausgabe von "zpool import", ging nicht aber mit -f hat es dann geklappt.
Ich dachte nach "zpool destroy Bla" ist alles wieder OK .... bei zpool import bekomme ich immer noch den Pool X angezeigt, mit Fehlern, import ist auch nicht möglich.
Was kann ich machen um den 'Pool X' loszuwerden?
Woher holt sich OmniOs die Infos für die Pools eigentlich?
Da ich so zu keinem Ergebnis kam versuchte ich die Platten zu formatieren. Was ich aber gleich bei der 1. Platte wieder abgebrochen habe obwohl da stand 'nicht abbrechen'.
Nach einem Reboot bekomme ich jetzt Meldungen vom fmd:
DISK-8000-4Q
fmadm repair ... - brachte bei
fmadm faulty - keine Ausgabe mehr
allerdings bleibt mir weiterhin der Zugriff auf die Platte verwehrt - format -e endet nach einer gewissen Zeit mit einer Fehlermeldung und
der fmd meldet sich wieder mit selbigen Fehler.
Wie bekomme ich die Platten wieder in einen Zustand so das OmniOS sie wieder verwenden kann?
Wie bekomme ich den fmd wieder sauber - abschalten ist ja auch keine Lösung(hat auch nichts gebracht - kein Zugriff auf die Platte)?
Kann leider zur Zeit nicht die genauen Fehlermeldungen posten - da ich testweise eine Platte mit LSI Config Utility formatiere und das dauert....
Was kann ich machen um den 'Pool X' loszuwerden?
- zpool destroy oder alle Platten neu initialisieren
Wie bekomme ich die Platten wieder in einen Zustand so das OmniOS sie wieder verwenden kann?
Platten initialisieren:
- an anderem Rechner z.B. PC -> NTFS
- mit napp-it Menü Disks - initialize
- per format
- per fdisk
- per parted
...
Woher holt sich OmniOs die Infos für die Pools eigentlich?
/etc/zfs/zpool.cache ( http://docs.oracle.com/cd/E19253-01/820-2313/gbbwc/index.html )
sowie als Info von den Platten selber
- zpool destroy oder alle Platten neu initialisieren
Wie bekomme ich die Platten wieder in einen Zustand so das OmniOS sie wieder verwenden kann?
Platten initialisieren:
- an anderem Rechner z.B. PC -> NTFS
- mit napp-it Menü Disks - initialize
- per format
- per fdisk
- per parted
...
Woher holt sich OmniOs die Infos für die Pools eigentlich?
/etc/zfs/zpool.cache ( http://docs.oracle.com/cd/E19253-01/820-2313/gbbwc/index.html )
sowie als Info von den Platten selber
Danke
Ja klar, 2 vCPU meinte ich, nicht vCores.
Über's Netz habe ich noch nicht versucht, hole ich aber nach.
Jupp, steht im Moment noch auf unlimited. Sofern ich nirgendwo anders Engpässe bekomme, wollte ich das auch erst mal so lassen.
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 527
aber compression=on oder?
Dann hast du getestet, wie schnell deine CPU komprimieren kann, aber nicht was deine Platten liefern.
millenniumpilot
Enthusiast
bei /dev/zero als Quelle frage ich mich eh, was da bei Dedup rauskommen soll ;-) Was soll den damit getestet werden? Ist doch vollkommen sinnfrei - oder?!
Schneller kannst Du keine grossen Files erzeugen:
cat /dev/zero > /tmp/bla -> würde ich nach 2-3s mit Strg-c abbrechen
ls -lh /tmp
-rw-r--r-- 1 root root 3,5G Jun 5 23:31 /tmp/bla
und das kann auch gut comprimieren:
root@otarget:~# gzip !$
gzip /tmp/bla
root@otarget:~# ll -h /tmp
-rw-r--r-- 1 root root 3,5M Jun 5 23:31 bla.gz
yes > /tmp/fasel ist viel langsamer
Und hier noch meine schnellste Festplatte:
root@otarget:~# dd if=/dev/zero of=/dev/null bs=1M count=50000
50000+0 records in
50000+0 records out
52428800000 bytes (52 GB) copied, 3,20964 s, 16,3 GB/s
millenniumpilot
Enthusiast
ich kenn den Syntax. Aber mit /dev/zero eine Deduplizierungsfunktion oder Komprimierung zu testen ist in meinen Augen sinnfrei. Du weist was die Quelle für Dateiinhalte erzeugt?
achja, kann ich übrigens toppen: OI virtualisiert unter ESXi5.0
root@fileserver:~# dd if=/dev/zero of=/dev/null bs=1M count=50000
50000+0 records in
50000+0 records out
52428800000 bytes (52 GB) copied, 2.25178 s, 23.3 GB/s
achja, kann ich übrigens toppen: OI virtualisiert unter ESXi5.0
root@fileserver:~# dd if=/dev/zero of=/dev/null bs=1M count=50000
50000+0 records in
50000+0 records out
52428800000 bytes (52 GB) copied, 2.25178 s, 23.3 GB/s
Zuletzt bearbeitet:
So, habe die VM jetzt nochmal aufgesetzt, weil ich die Embedded Variante ohne SWAP und Data Partition installieren wollte.
Jetzt komme ich bei gleichen Einstellungen in der loader.conf nur noch auf
Write: 120,53 MByte/s
Read: 129.73 MByte/s
Code:
dd if=/dev/zero of=testfile bs=1M count=10k
10240+0 records in
10240+0 records out
10737418240 bytes transferred in 84.953587 secs (126391582 bytes/sec)
dd if=testfile of=/dev/null bs=1M count=10k
10240+0 records in
10240+0 records out
10737418240 bytes transferred in 78.928948 secs (136039039 bytes/sec)Übers Netz per SCP erreiche ich:
Read: 60 MByte/s
Write: 50 MByte/s, bricht dann aber auf 37-42 MByte/s ein.
Also übers Netz und eigentlich auch per dd nicht sonderlich berauschend.
Irgendwer ne Idee?
Zuletzt bearbeitet:
Das ist irgendwie der Witz, oder? Einmal mit Profis...
ehm - das kannst du mir jetzt mal erklären. Bei dem Vorgang wird ein Testfile erzeugt welches auf die Platte geschrieben wird. Also testet man doch die HDD performance und nicht die Performance der CPU. Natürlich wird die CPU belastet, aber es wird ja trotzdem in den pool geschrieben ...
Es ging nie darum deup oder die Kompressierung zu testen. Dedup macht da so was von keinen Sinn und Kompressierrung funktioniert bei solchen Daten eben gut. Es ging rein um die Performance.
Zuletzt bearbeitet:
millenniumpilot
Enthusiast
Hallo,
aber wenn ich nur Nullen schreibe und die Komprimierung oder Dedup ist an, was denkst Du denn was dann auf die Platte geschrieben wird?
Also muss beides aus sein! Das alleine war der Hinweis an Dich. Oder ich nehme /dev/random.
aber wenn ich nur Nullen schreibe und die Komprimierung oder Dedup ist an, was denkst Du denn was dann auf die Platte geschrieben wird?
Also muss beides aus sein! Das alleine war der Hinweis an Dich. Oder ich nehme /dev/random.
Was dann je nach Implementierung evtl. nicht in der Lage ist, die nötigen Datenraten zu liefern.
---------- Post added at 09:26 ---------- Previous post was at 09:24 ----------
Wenn compression an ist, dann schreibst du effektiv ein paar K auf die Platte. Das sollte doch einleuchten, oder? Das is doch wie gesagt der Witz an der Sache, dass weniger Plattenplatz belegt wird. Meinst du, der schreibt das alles auf die Platte und geht dann nochmal drüber und löscht redundante Daten wieder? Das passiert alles, bevor die Daten auf die Platte gehen.
millenniumpilot
Enthusiast
Hallo gea,
Ich hatte gedacht, es gibt noch ein spezielles networkstartupscript, wo ich meine Zeile mit unterbringen kann, habe aber nichts gefunden.
Habe es nun wie oben vorgeschlagen mit einem separaten kleinen Einzeilerscript in /etc/init.d und Link gemacht.
Dieser Einzeiler ist aber nur beim OmniOS notwendig, bei Openindiana gehts auch ohne.
Ich hatte gedacht, es gibt noch ein spezielles networkstartupscript, wo ich meine Zeile mit unterbringen kann, habe aber nichts gefunden.
Habe es nun wie oben vorgeschlagen mit einem separaten kleinen Einzeilerscript in /etc/init.d und Link gemacht.
Dieser Einzeiler ist aber nur beim OmniOS notwendig, bei Openindiana gehts auch ohne.
Ok, korrektur. Ich habe es jetzt mal mit zwei MacBooks parallel getestet. Jetzt komme ich in Summe auf in etwa:
Read: 100 MByte/s
Write: 65 MByte/s
Scheinbar limitiert bei einem Macbook alleine die SSD....warum auch immer...wahrscheinlich weil sie zu 93% voll ist....
Ist der write Wert ok übers Netzwerk?
Edit:
Scheinbar hatte mein Server gestern keine Lust...
Habe mit dd nochmal getestet und komme jetzt auf
Write: 173.06 MByte/s
Read: 196.56 MByte/s
Denke das ist OK. Schreibend via Netzwerk könnte halt noch was schneller sein...
Zuletzt bearbeitet:
antilope114
Enthusiast
Kann mir vielleicht kurz jemand helfen: Ich habe eine 3TB SAS Festplatte mit 520 byte sector Formatierung. Solaris zeigt mir die Platte mit #format nicht an. Unter "iostat -en" sehe ich nur "sd6" - keinerlei WWN mit der ich die Platte ansprechen könnte um eine 512 byte sector Formatierung anzustoßen.
Der Log sagt:
sg3 utils habe ich schon kompiliert und installiert - folgendes habe ich vor zu nutzen:
sg_format --format --size=512 /dev/????
Wie kann ich die Platte korrekt ansprechen?
Danke
/edit: I solved the issue by using a Ubuntu 12.10 64bit Live cd.
From the terminal:
#sudo apt-get install sg3-utils
#sudo sg_scan -i
Note the dev path to the hard drive w/ 520 byte sectors, e.g. /dev/sg2
then proceed:
#sudo sg_format --format --size=512 --verbose /dev/sg2
PM me if you encounter any issues.
Der Log sagt:
sg3 utils habe ich schon kompiliert und installiert - folgendes habe ich vor zu nutzen:
sg_format --format --size=512 /dev/????
Wie kann ich die Platte korrekt ansprechen?
Danke
/edit: I solved the issue by using a Ubuntu 12.10 64bit Live cd.
From the terminal:
#sudo apt-get install sg3-utils
#sudo sg_scan -i
Note the dev path to the hard drive w/ 520 byte sectors, e.g. /dev/sg2
then proceed:
#sudo sg_format --format --size=512 --verbose /dev/sg2
PM me if you encounter any issues.
Zuletzt bearbeitet:
millenniumpilot
Enthusiast
Hallo Gea,
ich wollte gerade für diesen Zweck unter Nappit 0.9c1 und OmniOS 3 auto-snap jobs erstellen.
Diese kann ich auch erfolgreich erstellen mit den Namen daily (ist vorgeschlagen), wochen und monate.
Wenn ich dann aber anschließend die Startzeit nochmals verändern möchte (beim Anlegen stehen nicht alle Zeiten zur Verfügung) erhalte ich IMMER die Fehlermeldung: "unallowed or empty snapname", d.h. für mich, die Komandozeile wird von Nappit wohl falsch zusammengebaut.
Desweiteren ist mir aufgefallen, das beim Autoserviceintervall von 15min keine Jobs ausgeführt werden, die nicht auf 0, 15, 30 oder 45 Minuten enden.
EIn Job mit einer Startzeit 20:40 wird niemals ausgeführt, auch nicht wenn der nächste Autojobzyklus bei 20:45 ausgeführt wird. Ist das so gewollt? Ich hatte gedacht, diese werden dann "nachgeholt"
Und zum Schluss noch eine gaaaaaanz peinliche Frage: was heist eigendlich z.B. every-2BC? Every-2 usw. ist mir klar.
Gruß Millenniumpilot
ich wollte gerade für diesen Zweck unter Nappit 0.9c1 und OmniOS 3 auto-snap jobs erstellen.
Diese kann ich auch erfolgreich erstellen mit den Namen daily (ist vorgeschlagen), wochen und monate.
Wenn ich dann aber anschließend die Startzeit nochmals verändern möchte (beim Anlegen stehen nicht alle Zeiten zur Verfügung) erhalte ich IMMER die Fehlermeldung: "unallowed or empty snapname", d.h. für mich, die Komandozeile wird von Nappit wohl falsch zusammengebaut.
Desweiteren ist mir aufgefallen, das beim Autoserviceintervall von 15min keine Jobs ausgeführt werden, die nicht auf 0, 15, 30 oder 45 Minuten enden.
EIn Job mit einer Startzeit 20:40 wird niemals ausgeführt, auch nicht wenn der nächste Autojobzyklus bei 20:45 ausgeführt wird. Ist das so gewollt? Ich hatte gedacht, diese werden dann "nachgeholt"
Und zum Schluss noch eine gaaaaaanz peinliche Frage: was heist eigendlich z.B. every-2BC? Every-2 usw. ist mir klar.
Gruß Millenniumpilot
1.
wie änderst du die Zeiten?
- In der Joblist (Menü Jobs) auf Tag/Stunde etc klicken und ändern?
Ich habs gerade noch mal getestet und konnte keinen Fehler feststellen
Zum Ändern allgemeiner Jobparameter auf die Jobid klicken
2.
Zeiten sind Zeitpunkte, nicht irgendwann später.
Wenn es also z.B 9:41 sein soll, dann muss der Jobdienst auf 1 Min eingestellt sein (prüfen, ob Jobs anstehen).
Steht er auf 15min, dann gehen nur 15 Minuten-Intervalle
3.
ABCD sind 6-Stunden-Intervalle von 0 bis 23 Uhr
Damit kann man z.B. zu den Arbeitsstunden mehr Snaps machen lassen als nachts
(siehe Info auf der Seite beim Anlegen von Jobs)
wie änderst du die Zeiten?
- In der Joblist (Menü Jobs) auf Tag/Stunde etc klicken und ändern?
Ich habs gerade noch mal getestet und konnte keinen Fehler feststellen
Zum Ändern allgemeiner Jobparameter auf die Jobid klicken
2.
Zeiten sind Zeitpunkte, nicht irgendwann später.
Wenn es also z.B 9:41 sein soll, dann muss der Jobdienst auf 1 Min eingestellt sein (prüfen, ob Jobs anstehen).
Steht er auf 15min, dann gehen nur 15 Minuten-Intervalle
3.
ABCD sind 6-Stunden-Intervalle von 0 bis 23 Uhr
Damit kann man z.B. zu den Arbeitsstunden mehr Snaps machen lassen als nachts
(siehe Info auf der Seite beim Anlegen von Jobs)
Killer Chris
Enthusiast
Moin Leute,
bin gerade in einem kleinen dilemma:
Für meine ESX Farm brauche ich Storage und hab gerade noch ein NexentaStor laufen, will aer aus dem 18TB Limit raus etc und bin daher nochmal am überlegen wie ich den Storage am sinnvollsten aufbaue um für die virtuellen Maschinen ein guten Kompromiss aus Performance und Speicherplatz zu bekommen (Fileserver wird ebenfalls virtualisiert betrieben).
Zur verfügung stehen 13x 2TB Platten (9x WD Black, 4x WD Red), jetzt ist die Frage ob: 6x Mirror (12TB), 4x Raidz1 mit 3 Platten (16TB) oder 2x Raidz2 mit 6 Platten (16TB).
Am flexibelsten, aber in sachen Speicherplatz grenzwertig, ist Lösung 1.
Lösung 2 ist die aktuell von mir präferierte weil ich dann noch ein weiteres Raidz1 dran hängen kann bei Bedarf (16 Plattenslots).
Lösung 3 ist schlecht zu erweitern ohne gleich nen 2tes Case zu kaufen und ich hab weniger Plattenspindel die entsprechend in der Performance skalieren - oder habe ich hier ein denkfehler drin?
Als L2ARC und ZIL werden zusätzlich je eine 256GB Samsung 830er SSD genutzt.
Nächster Punkt:
OpenIndiana als OS, spricht etwas dagegen? Genutzt wird nur ZFS mit Snapshots und NFS Exports zum ESX.
Grafisches Interface brauche ich nicht, hab die Console lieber ;-)
bin gerade in einem kleinen dilemma:
Für meine ESX Farm brauche ich Storage und hab gerade noch ein NexentaStor laufen, will aer aus dem 18TB Limit raus etc und bin daher nochmal am überlegen wie ich den Storage am sinnvollsten aufbaue um für die virtuellen Maschinen ein guten Kompromiss aus Performance und Speicherplatz zu bekommen (Fileserver wird ebenfalls virtualisiert betrieben).
Zur verfügung stehen 13x 2TB Platten (9x WD Black, 4x WD Red), jetzt ist die Frage ob: 6x Mirror (12TB), 4x Raidz1 mit 3 Platten (16TB) oder 2x Raidz2 mit 6 Platten (16TB).
Am flexibelsten, aber in sachen Speicherplatz grenzwertig, ist Lösung 1.
Lösung 2 ist die aktuell von mir präferierte weil ich dann noch ein weiteres Raidz1 dran hängen kann bei Bedarf (16 Plattenslots).
Lösung 3 ist schlecht zu erweitern ohne gleich nen 2tes Case zu kaufen und ich hab weniger Plattenspindel die entsprechend in der Performance skalieren - oder habe ich hier ein denkfehler drin?
Als L2ARC und ZIL werden zusätzlich je eine 256GB Samsung 830er SSD genutzt.
Nächster Punkt:
OpenIndiana als OS, spricht etwas dagegen? Genutzt wird nur ZFS mit Snapshots und NFS Exports zum ESX.
Grafisches Interface brauche ich nicht, hab die Console lieber ;-)
Zuletzt bearbeitet:
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 527
wenn dir der Platz reicht, würd ich den Mirror nehmen, der ist schnell und auch gut erweiterbar.
Ansonsten würd ich was mit Raidz2 nehmen.
Bei Openindiana tut sich mittlerweile wieder mehr, das kannst du bedenkenlos nehmen. Anonsten natürlich OmniOS.
cu
Ansonsten würd ich was mit Raidz2 nehmen.
Bei Openindiana tut sich mittlerweile wieder mehr, das kannst du bedenkenlos nehmen. Anonsten natürlich OmniOS.
cu
millenniumpilot
Enthusiast
Hallo Gea,
ja, genau so. Wie ich es gerade sehe, betrifft das nur das Nappit unter OmniOS, frisch installiert. Beim Nappit unter Openindiana geht es bei mir auch.
da habe ich nichts gefunden, wo soll das sein? Ich kenne nur "help: soon.."
Gruß Millenniumpilot
ja, genau so. Wie ich es gerade sehe, betrifft das nur das Nappit unter OmniOS, frisch installiert. Beim Nappit unter Openindiana geht es bei mir auch.
Danke, habe ich nicht gewusst.
da habe ich nichts gefunden, wo soll das sein? Ich kenne nur "help: soon.."
Gruß Millenniumpilot
Killer Chris
Enthusiast
Wo liegt der Unterschied zwischen OmniOS und Openindiana bzw was spricht allgemein für OmniOS?
Als Alternative Zu NexentaStor CE würde ich OmniOS empfehlen. Im Gegensatz zu NexentaStor CE darf das kommerziell genutzt werden und es gibt keine 18 TB Raw Grenze. Man kann es ebenfalls als appliance mit Web-UI oder pur per CLI bedienen.
Im Gegensatz zu OI wird es erheblich besser gepflegt - es ist auch aktueller. So gibt es jetzt die dritte Stable, Fehlerbehebungen und alle zwei Wochen eine neie Zwischenversion. Ansonsten ist Omni extrem ähnlich zu OI server-edition. Bei Bedarf gibt es kommerziellen Support.
Beim ZFS Poolaufbau kann man ganz klar zu Multiple-Raid-Z2 für einen Fileserver raten. Als schnellen Datastore für ESXi würde ich allerdings immer viele Mirrors oder SSD only Pools bevorzugen, auch wenns teurer wird. Raid-Z Pools aus großen "green" Platten sind immer schlecht wenns um I/O geht. Ich würde eigentlich statt einem faulen Kompromiß zu einem schnelleren (Raid-10 datastore, eventuell SSD Pool) und einem langsameren (Raid-Z Fileserver) Pool raten. Die Samsung ist für Arc gut, als ZIL ist sie aber weniger geeignet (kein Puffer-Kondensator und nicht wirklich schnell für ein ZIL).
---------- Post added at 16:55 ---------- Previous post was at 16:52 ----------
- ich habes auch nochmal unter Omni getestet (habe hier zu Hause OI) aber kein Problem bei Zeiten einstellen entdeckt.
- Der Hinweis ist auf der Seite "snap - create autosnap" unter dem Formular
millenniumpilot
Enthusiast
Hallo Gea,
ich danke Dir, brauche wohl ein Notebook mit größerem Display ;-)
Der Fehler bei der Zeiteinstellung tauchte eben auch unter Openindiana auf. Ich muss schauen, wann das nun wirklich ausgelöst wird, wenn ich alle Jobs anzeigen lasse oder nur Snaps usw., also Aufgaben oder Aufgaben->Snap. Oder nur beim Editieren von ganz alten, also mit älteren Versionen von Nappit erstellten oder nur bei frischen Jobs.
Bisher habe ich leider noch kein System beim Auftreten der Meldung "unallowed or empty snapname" entdecken können.
Edit:
Gea, ich glaube ich habe den Fehler gefunden.
Wenn ich unter Jobs->snap->create autosnap einen Job anlege, erscheinen die schon angelegten und auch die neu angelegten Jobs oben auf der Seite in einer Übersicht. Wenn ich hier die Zeiten ändere, bekomme ich besagte Fehlermeldung.
Gehe ich dagegen auf Jobs oder auf Jobs->snap dann kann ich alles wie gewünscht ändern.
Kannst Du mein Kauderwelch nachvollziehen?
ich danke Dir, brauche wohl ein Notebook mit größerem Display ;-)
Der Fehler bei der Zeiteinstellung tauchte eben auch unter Openindiana auf. Ich muss schauen, wann das nun wirklich ausgelöst wird, wenn ich alle Jobs anzeigen lasse oder nur Snaps usw., also Aufgaben oder Aufgaben->Snap. Oder nur beim Editieren von ganz alten, also mit älteren Versionen von Nappit erstellten oder nur bei frischen Jobs.
Bisher habe ich leider noch kein System beim Auftreten der Meldung "unallowed or empty snapname" entdecken können.
Edit:
Gea, ich glaube ich habe den Fehler gefunden.
Wenn ich unter Jobs->snap->create autosnap einen Job anlege, erscheinen die schon angelegten und auch die neu angelegten Jobs oben auf der Seite in einer Übersicht. Wenn ich hier die Zeiten ändere, bekomme ich besagte Fehlermeldung.
Gehe ich dagegen auf Jobs oder auf Jobs->snap dann kann ich alles wie gewünscht ändern.
Kannst Du mein Kauderwelch nachvollziehen?
Zuletzt bearbeitet:
bestätigt, wird gefixt
Kann man eigentlich unter OmniOS das LZ4 auch am rpool (rootpool) aktivieren? Wenn nein, wird das noch kommen? (Habe glaube ich mal irgendwas von Inkompatibilität mit dem Boot-Environment und lz4 gelesen?)
PS: Oben wurde mal gesagt das lz4 vorteile bei arc2 und ZIL bringt? Die Compression drückt doch nur die Durchsatzraten sodass eine Cache-SSD mit lz4 weniger Durchsatz hat (aber weniger drauf geschrieben wird), was aber beim Cache doch kein Sinn macht oder?
@gea: Mittlerweile habe ich auf dem Napp-it-to-go @ N40L nur noch 1,9GB von 16GB frei. Wird das mit der Zeit zu einem Problem?
(Ausser OmniOS- und Nappit-Updates wurde und wird auf dem rpool nix gemacht.
PS: Was haltet ihr eigentlich HIER von? Mit 10K ist die Access-Time ja bestimmt gut aber sequentiell sind die alten HDDs nicht soooo tolle oder?
(Der Preis ist ja Top und für OmniOS-Mirror reicht der Platz auch) ggf. sogar 2x Mirror @ raid0?
PS: Oben wurde mal gesagt das lz4 vorteile bei arc2 und ZIL bringt? Die Compression drückt doch nur die Durchsatzraten sodass eine Cache-SSD mit lz4 weniger Durchsatz hat (aber weniger drauf geschrieben wird), was aber beim Cache doch kein Sinn macht oder?
@gea: Mittlerweile habe ich auf dem Napp-it-to-go @ N40L nur noch 1,9GB von 16GB frei. Wird das mit der Zeit zu einem Problem?
(Ausser OmniOS- und Nappit-Updates wurde und wird auf dem rpool nix gemacht.
PS: Was haltet ihr eigentlich HIER von? Mit 10K ist die Access-Time ja bestimmt gut aber sequentiell sind die alten HDDs nicht soooo tolle oder?
(Der Preis ist ja Top und für OmniOS-Mirror reicht der Platz auch) ggf. sogar 2x Mirror @ raid0?
Zuletzt bearbeitet:
