ja und diese Fehlermeldung erscheint jetzt ....
Update... eine Neuinstallation hat die Fehlermeldungen beseitigt, leider bleiben die SSD "removed"
Ein Format Befehl zeigt an das die SSD da sind jedoch "unkown" sind.
Zuletzt bearbeitet:
ja und diese Fehlermeldung erscheint jetzt ....
Update... eine Neuinstallation hat die Fehlermeldungen beseitigt, leider bleiben die SSD "removed"
Ein Format Befehl zeigt an das die SSD da sind jedoch "unkown" sind.
zur Fehlermeldung sata und timeout
OmniOS 151030 setzt jetzt intern ein kürzeres disk timeout und aktiviert sata hotplug (sehr sinnvoll).
Wenn das zusätzlich in /etc/system (manuell oder napp-it System - Tuning) aktiviert wird, kommt der (nicht weiter kritische) Hinweis. Diese Angaben in /etc/system auskommentieren (macht aktuelles System - Tuning als default)
Zur Fehlermeldung io device retired
Wenn der Fehler Management Dienst von Solaris ein Device sieht das fortlaufend Errors erzeugt, wird das dauerhaft offline gesetzt damit keine Folgeschäden entstehen (retired). Um das Device wieder zu nutzen, muss man den Fehler quittieren, siehe Menü System > Faults > Repair
zur NVMe
Das Problem kann man lösen indem die NVMe neu formatiert wird, meist reicht ein Anlegen eines Pools z.B. via zpool create test c9t00... Danach sollte die NVMe wieder mit korrektem Namen erkannt werden.
ps
In der aktuellen Pro/Dev habe ich das unknown disk Problem bereits beseitigt
OmniOS 151030 setzt jetzt intern ein kürzeres disk timeout und aktiviert sata hotplug (sehr sinnvoll).
Wenn das zusätzlich in /etc/system (manuell oder napp-it System - Tuning) aktiviert wird, kommt der (nicht weiter kritische) Hinweis. Diese Angaben in /etc/system auskommentieren (macht aktuelles System - Tuning als default)
Zur Fehlermeldung io device retired
Wenn der Fehler Management Dienst von Solaris ein Device sieht das fortlaufend Errors erzeugt, wird das dauerhaft offline gesetzt damit keine Folgeschäden entstehen (retired). Um das Device wieder zu nutzen, muss man den Fehler quittieren, siehe Menü System > Faults > Repair
zur NVMe
Das Problem kann man lösen indem die NVMe neu formatiert wird, meist reicht ein Anlegen eines Pools z.B. via zpool create test c9t00... Danach sollte die NVMe wieder mit korrektem Namen erkannt werden.
ps
In der aktuellen Pro/Dev habe ich das unknown disk Problem bereits beseitigt
Zuletzt bearbeitet:
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Bug #8583: Windows 10 fails to delete read-only files with SMB2 - illumos gate - illumos
Scheint nun endlich gefixt zu sein. Kann man damit in OmniOS im November rechnen?
Scheint nun endlich gefixt zu sein. Kann man damit in OmniOS im November rechnen?
Gordon Ross (Nexenta) ist gerade dabei einiges aus NexentaStor5 (SMB3 fällt mir da auch ein) in Illumos zu integrieren. Bei OpenIndiana steht das dann unmittebar zur Verfügung (wie native ZFS Verschlüssellung). OmniOS ist da etwas konservativer. Da ist es meist auch sofort in der Bloody (eben wie auch Verschlüssellung). Ich würde davon ausgehen, dass es in der nächsten Stable 151032 (Oktober/November) drin ist.
Ansonsten, fragen: omniosorg/Lobby - Gitter
Die Entwickler von OmniOS sitzen in der Schweiz und UK
Ansonsten, fragen: omniosorg/Lobby - Gitter
Die Entwickler von OmniOS sitzen in der Schweiz und UK
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Weißt du denn wie es sich verhalten wird? Wird man die Dateien einfach löschen können oder kommt ne Fehlermeldung? Bei Windowsserver ist es meine ich so dass man die Dateien einfach löschen kann, was in meinen Augen logisch ist weil ein Schreibschutz auf eine Datei soll sie ja nur gegen Veränderung schützen. Löschen ist ja eigentlich eine Operation im Dateisystem und nicht an einer Datei selbst. Zumindest ist mein Verständnis so.
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Ist damit denn nur die "Grundfunktionalität" gemeint? Weil SMB3 hat ja auch ne Reihe von Features wie Multichannel?
Ich habe keine Details.
Multichannel ist bereits in SMB 3.0 enthalten. In NexentaStor5 ist SMB 3.02 enthalten. Deshalb wird es vermutlich 3.02 sein. Ob 3.1.1 mit Verschlüssellung kommt wage ich im Moment zu bezweifeln. Nach den bisherigen Nexenta Erfahrungen würde das erst in NexentaStor kommen und dann mit Verzögerung in Illumos.
Multichannel ist bereits in SMB 3.0 enthalten. In NexentaStor5 ist SMB 3.02 enthalten. Deshalb wird es vermutlich 3.02 sein. Ob 3.1.1 mit Verschlüssellung kommt wage ich im Moment zu bezweifeln. Nach den bisherigen Nexenta Erfahrungen würde das erst in NexentaStor kommen und dann mit Verzögerung in Illumos.
Ja, Solaris hat die meisten Features bei ZFS, ist meist auch der schnellste ZFS Server, ist jedoch kommerzielle Software. Wenn man das kommerziell nutzt werden wenigstens 800 Euro/Jahr fällig. (Ok, Windows Server 2019 und NexentaStor ist auch nicht billig).
Die SMB3 Entwicklung bei Illumos nimmt richtig Fahrt auf
Neuestes Feature: SMB für ZFS Cluster/ HA failover
Implement SMB3 persistent handles
(part of making SMB "cluster aware")
Steps to Reproduce:
Connect an SMB3 client (Win2012 or later)
Restart the SMB service, or force a fail-over
Take a network capture (from the client is easiest)
Expected Results:
SMB3 client should reclaim it's CA handles after the restart or fail-over.
Actual Results:
SMB3 client has to re-establish it's open handles (as seen in the network capture)
Search - illumos
Neuestes Feature: SMB für ZFS Cluster/ HA failover
Implement SMB3 persistent handles
(part of making SMB "cluster aware")
Steps to Reproduce:
Connect an SMB3 client (Win2012 or later)
Restart the SMB service, or force a fail-over
Take a network capture (from the client is easiest)
Expected Results:
SMB3 client should reclaim it's CA handles after the restart or fail-over.
Actual Results:
SMB3 client has to re-establish it's open handles (as seen in the network capture)
Search - illumos
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Hat schon jemand den HPE Microserver Gen10 mal mit OmniOS betrieben und kann sagen ob das läuft, sprich die Hardware unterstützt wird?
Netzwerkchip ist Broadcom 5720
Feature #8947: Support the Marvell 88SE9230 PCIe to SATA controller - illumos gate - illumos
In Illumos scheint der Sata Controller zu funktionieren laut eines Users. Marvell 88SE9230 SATA Controller
Würde diesen Controller am liebsten durchreichen per Exsi.
Hat das schon jemand mal versucht?
Der (5.) interne Sata Board kommt wohl direkt vom AMD Chipsatz. In dem Fall würde es doch theoretisch möglich sein Exsi auf den USB Stick, Esxi VMs auf ne Sata SSD an Port5 und Port1-4 durchgereicht an ne OmniOS VM.
Netzwerkchip ist Broadcom 5720
Feature #8947: Support the Marvell 88SE9230 PCIe to SATA controller - illumos gate - illumos
In Illumos scheint der Sata Controller zu funktionieren laut eines Users. Marvell 88SE9230 SATA Controller
Würde diesen Controller am liebsten durchreichen per Exsi.
Hat das schon jemand mal versucht?
Der (5.) interne Sata Board kommt wohl direkt vom AMD Chipsatz. In dem Fall würde es doch theoretisch möglich sein Exsi auf den USB Stick, Esxi VMs auf ne Sata SSD an Port5 und Port1-4 durchgereicht an ne OmniOS VM.
Zuletzt bearbeitet:
lt illumos HCL - WIP sollte der Broadcom laufen.
Alles andere ist weit weg von "läuft erwiesenermaßen problemlos"
Einfach testen und zur Not einen HBA einbauen.
Alles andere ist weit weg von "läuft erwiesenermaßen problemlos"
Einfach testen und zur Not einen HBA einbauen.
Wenn man sich die Schreib/Leseperformance einer Platte oder eines Array abhängig von der Größe der Datenblöcke ansieht, so sieht man dass die Leistung unterhalb von sagen wir mal 1 MB übel einbricht. Ein Schreibcache muss in erster Linie vermeiden, dass derart kleine Datenblöcke geschrieben werden. Das ist die Hauptaufgabe des RAM-Schreibcaches. Sammeln kleiner Writes um daraus ein großes schnelles sequentielles Write zu machen. Kleine Writes erhöhen darüber massiv die Fragmentierung. Auch SSDs sind da schlecht da bei denen erst mal eine Page gelesen und gelöscht werden muss bevor ein kleines Write mit der neuen Page geschrieben wird.
Der Default RAM-Schreib-Cache bei Solaris sammelt ca 5s Write, also bei 1G Netzwerk ca 500 MB, bei 10G ca 5 GB. Ist der Cache voll, muss er sequentiell auf Platte. Das dauern n Sekunden.
Würde man den Ramcache auf das doppelte erhöhen, so hätte man die doppelte Zeit volle Netzwerkperformance, müsste anschließend aber doppelt so lange warten bis der Cache auf dem Pool ist. Es gäbe sicher ein use case wo das vorteilhaft wäre. Meist aber ist es egal. Gemittelt über der Zeit hat man gleiche Performmance da der Pool bei 5GB vs z.B. 10 GB Schreiben ähnlich schnell ist.
Ich würde den Ramcache daher auf default lassen. Der zusätzliche Arc Readcache bringt im Zweifel mehr zumal dann weniger oft von Platte gelesen werden muss (Daten im Lesecache) und das natürlich der Schreibperformance zugute kommt wenn während des Schreibens nicht auch noch gelesen werden muss.
Bei Open-ZFS (OmniOS, Free-BSD, ZoL) ist der Schreibcache nicht auf 5s gelegt sondern abhängig von der Ramgröße. Ist er halb voll geht er auf Platte und die andere Hälfte arbeitet solange als Cache. Bei konstantem Schreiben ist das schneller. Bei kurzfristigen Schreibvorgängen ist der Solaris Weg schneller. Aber auch bei Open-ZFS ist der Defaultwert (10% RAM, max 4GB) ok.
Da der Cache große sequentielle Schreibvorgänge auch bei small random write erzeugt, ist das Ziel dass der Pool sequentiell mindestens so schnell ist (besser deutlich schneller) ist als die Netzwerkperformance da neben dem Schreiben ja auch gelesen wird (Daten und Metadaten, letztere muss man auch vor dem Schreiben lesen)
Ach ja, ein Crash und der Ramcache ist verloren. Um das zu vermeiden muss man sync aktivieren.. Ein Slog zum Absichern des Ramcache muss dann entsprechend groß sein (mindestens 2 x Ramcache) und schnell sein.
Der Default RAM-Schreib-Cache bei Solaris sammelt ca 5s Write, also bei 1G Netzwerk ca 500 MB, bei 10G ca 5 GB. Ist der Cache voll, muss er sequentiell auf Platte. Das dauern n Sekunden.
Würde man den Ramcache auf das doppelte erhöhen, so hätte man die doppelte Zeit volle Netzwerkperformance, müsste anschließend aber doppelt so lange warten bis der Cache auf dem Pool ist. Es gäbe sicher ein use case wo das vorteilhaft wäre. Meist aber ist es egal. Gemittelt über der Zeit hat man gleiche Performmance da der Pool bei 5GB vs z.B. 10 GB Schreiben ähnlich schnell ist.
Ich würde den Ramcache daher auf default lassen. Der zusätzliche Arc Readcache bringt im Zweifel mehr zumal dann weniger oft von Platte gelesen werden muss (Daten im Lesecache) und das natürlich der Schreibperformance zugute kommt wenn während des Schreibens nicht auch noch gelesen werden muss.
Bei Open-ZFS (OmniOS, Free-BSD, ZoL) ist der Schreibcache nicht auf 5s gelegt sondern abhängig von der Ramgröße. Ist er halb voll geht er auf Platte und die andere Hälfte arbeitet solange als Cache. Bei konstantem Schreiben ist das schneller. Bei kurzfristigen Schreibvorgängen ist der Solaris Weg schneller. Aber auch bei Open-ZFS ist der Defaultwert (10% RAM, max 4GB) ok.
Da der Cache große sequentielle Schreibvorgänge auch bei small random write erzeugt, ist das Ziel dass der Pool sequentiell mindestens so schnell ist (besser deutlich schneller) ist als die Netzwerkperformance da neben dem Schreiben ja auch gelesen wird (Daten und Metadaten, letztere muss man auch vor dem Schreiben lesen)
Ach ja, ein Crash und der Ramcache ist verloren. Um das zu vermeiden muss man sync aktivieren.. Ein Slog zum Absichern des Ramcache muss dann entsprechend groß sein (mindestens 2 x Ramcache) und schnell sein.
Zuletzt bearbeitet:
Läuft nappit nicht schon ab ein paar GB? Mir läuft das NFS Storage mit 6GB aktuell, da mein Mainboard ne Macke hat, und so nur 32GB zur Verfügung stehen im Moment.
Aber 200GB für Storage im Homelab? Wie christlich muss man sein. Ich schiel da ja auf 128GB gesamt auf Ende Jahr. Aber selbst dann sieht der Filer nicht mehr als 32GB.
Ich hatte ursprünglich meinen RAM für >300 € den Riegel gekauft (32 GB RDIMM), mittlerweile kostet ein Riegel ~ 130 €.
Brauche den RAM auch noch für andere VMs aber Solaris soll definitiv nicht zu kurz kommen.
Außerdem will ich endlich mal Octachannel nutzen.
@gea, danke für die ausführliche Aufklärung. Hatte gedacht, das sämtliche Writes erstmal in den RAM Cache wandern. Ebenso dachte ich, Solaris hätte ebenfalls das 10% RAM max 4GB Limit, und die anderen OpenZFS Distris hätten diese Regelung übernommen. Man lernt zum Glück nie aus
. Für den Speedup von Sync Writes habe ich eine 30 GB Partition auf einer 900p Optane als Slog am Pool angeflanscht. Auf dem anderen Speicherplatz der Optane liegt Solaris selbst und der der verbleibende Rest wird als L2ARC genutzt.
Brauche den RAM auch noch für andere VMs aber Solaris soll definitiv nicht zu kurz kommen.
Außerdem will ich endlich mal Octachannel nutzen.
@gea, danke für die ausführliche Aufklärung. Hatte gedacht, das sämtliche Writes erstmal in den RAM Cache wandern. Ebenso dachte ich, Solaris hätte ebenfalls das 10% RAM max 4GB Limit, und die anderen OpenZFS Distris hätten diese Regelung übernommen. Man lernt zum Glück nie aus
. Für den Speedup von Sync Writes habe ich eine 30 GB Partition auf einer 900p Optane als Slog am Pool angeflanscht. Auf dem anderen Speicherplatz der Optane liegt Solaris selbst und der der verbleibende Rest wird als L2ARC genutzt.Sir Diablo
Enthusiast
@gea
Bei nem AllFlash sync=always RAIDZ für iSCSI zvols, was ist da das theoretisch bessere logbias=throughoutput oder latency - merk da irgedwie keinen Unterschied.
Oder betrifft diese Einstellung ausschließlich Pools mit slog?
Bei nem AllFlash sync=always RAIDZ für iSCSI zvols, was ist da das theoretisch bessere logbias=throughoutput oder latency - merk da irgedwie keinen Unterschied.
Oder betrifft diese Einstellung ausschließlich Pools mit slog?
Zuletzt bearbeitet:
Wenn man ein Slog hat und das nutzen möchten, ist latency das richtige.
https://docs.oracle.com/cd/E19253-01/819-5461/givdo/index.html
Ich habe diese Einstellung aber noch nie genutzt.
- - - Updated - - -
64Bit Solaris läuft ab 2GB stabil. Andere Betriebssysteme brauchen eventuell für ZFS etwas mehr aber nicht entscheidend mehr. Dann hat man aber keinen Ram als Readcache. Da ZFS Daten über den Pool so gleichmäßig wie möglich verteilt und wegen CopyOnWrite eh eine höhere Fragmentierung erzeugt, ist die Pool iops für die Zugriffsperformance entscheidend. Bei einem reinen Optane Pool ist ZFS dann trotz wenig RAM schon richtig schnell. Wenn man eine alte WD green Platte hat, kann man froh sein wenn man dann 3 MB/s hat.
Da der Ramcache die letzten Random Zugriffe und das Lesen der Metadate cacht, kann dann aber selbst so eine alte und grottig langsame WD green volle Netzwerkperformance liefern da wiederholte Zugriffe aus dem Ram bedient werden.
Geht man davon aus dass ca 1% der Daten Metadaten sind die man gerne cachen möchte und man aktive Random Nutzerdaten cachen möchte, kann man den Rambedarf abschätzen. Ein großer Mailserver mit vielen Usern und Millionen kleinen Dateien kann da schon mal > 128GB RAM haben wollen. Bei wenigen aktiven Daten ist der sinnvolle Rambedarf viel niedriger. Da kann es sein das der Sprung von 32GB auf 64GB gerade noch merkbar ist, der Sprung von 64 GB auf 128GB oder mehr aber bedeutungslos.
Ein Speicherausbau bis ca 64 GB bringt aber meistens noch eine deutliche Performanceverbesserung. Weniger als 4GB RAM sollte es aber nicht sein. Macht dann keinen Spass und fühlt sich eher an wie USB-Stick.
Sequentielle Daten (Videos etc) werden grundsätzlich nicht gecacht. Ein paar Videos würden sonst den größten Cache wegfressen. Man kann allenfalls einen L2Arc mit aktiviertem read-ahead nutzen. Das verbessert eventuell das sequentielle Lesen etwas.
https://docs.oracle.com/cd/E19253-01/819-5461/givdo/index.html
Ich habe diese Einstellung aber noch nie genutzt.
- - - Updated - - -
64Bit Solaris läuft ab 2GB stabil. Andere Betriebssysteme brauchen eventuell für ZFS etwas mehr aber nicht entscheidend mehr. Dann hat man aber keinen Ram als Readcache. Da ZFS Daten über den Pool so gleichmäßig wie möglich verteilt und wegen CopyOnWrite eh eine höhere Fragmentierung erzeugt, ist die Pool iops für die Zugriffsperformance entscheidend. Bei einem reinen Optane Pool ist ZFS dann trotz wenig RAM schon richtig schnell. Wenn man eine alte WD green Platte hat, kann man froh sein wenn man dann 3 MB/s hat.
Da der Ramcache die letzten Random Zugriffe und das Lesen der Metadate cacht, kann dann aber selbst so eine alte und grottig langsame WD green volle Netzwerkperformance liefern da wiederholte Zugriffe aus dem Ram bedient werden.
Geht man davon aus dass ca 1% der Daten Metadaten sind die man gerne cachen möchte und man aktive Random Nutzerdaten cachen möchte, kann man den Rambedarf abschätzen. Ein großer Mailserver mit vielen Usern und Millionen kleinen Dateien kann da schon mal > 128GB RAM haben wollen. Bei wenigen aktiven Daten ist der sinnvolle Rambedarf viel niedriger. Da kann es sein das der Sprung von 32GB auf 64GB gerade noch merkbar ist, der Sprung von 64 GB auf 128GB oder mehr aber bedeutungslos.
Ein Speicherausbau bis ca 64 GB bringt aber meistens noch eine deutliche Performanceverbesserung. Weniger als 4GB RAM sollte es aber nicht sein. Macht dann keinen Spass und fühlt sich eher an wie USB-Stick.
Sequentielle Daten (Videos etc) werden grundsätzlich nicht gecacht. Ein paar Videos würden sonst den größten Cache wegfressen. Man kann allenfalls einen L2Arc mit aktiviertem read-ahead nutzen. Das verbessert eventuell das sequentielle Lesen etwas.
Hmmm, mein Storage besteht sozusagen nur aus VMDK's. Einmal auf Consumer SSD für die VM's, einmal auf WD Gold für Backups. Allenfalls ein paar ISOs liegen noch da drauf. Ich nehme an, das sind dann alles sequentielle Dateien? Sprich da würde mir mehr Speicher so gut wie gar nichts bringen?
Ich verwende schon länger eine SW mit Namen infuse von firecore um z.B. Videos von meinem OmniOSce Fileserver zu streamen. Diese Software kann unter anderem Verbindungen mit SMB aufbauen und unterscheidet dabei zwischen SMB1, SMB2 und SMB3. Seit über 18 Monaten konnte ich nur Verbindungen mit SMB1 aufbauen. Gestern habe ich die aktuelle Bloody von OmniOSce ausprobiert und plötzlich funktioniert SMB3. Das macht Hoffnung.
SMB3 ist bei OmniOS angekündigt auf Version 151032 stable (vorr. November 2019). Bei OI und bloody früher.
omniosorg/Lobby - Gitter
- - - Updated - - -
Ja, das gibt eher eine sequentielle Last. Dafür sind zumindest viel Ram z.B. > 64 GB weniger hilfreich für Top-Performance als z.B. mehr oder schnellere vdevs.
Verständnissfrage:
Beim Start von ESXI / Napp IT (OmniOS v11 r151030m) wird folgendes angezeigt:
Cache und Log durch eine Optane 900P ohne Funktion ?
Der Benchmark hierzu sieht wie folgt aus :
Nachdem manuell unter Disk / Partition enable die Optane aufgerufen wird, stehen jetzt plötzlich die passenden Angaben zu Cache und log drin:
Der Benchmark hierzu sieht wie folgt aus :
Ist das so richtig oder liegt ein config fehler vor ?
Beim Start von ESXI / Napp IT (OmniOS v11 r151030m) wird folgendes angezeigt:
Cache und Log durch eine Optane 900P ohne Funktion ?
Der Benchmark hierzu sieht wie folgt aus :
Nachdem manuell unter Disk / Partition enable die Optane aufgerufen wird, stehen jetzt plötzlich die passenden Angaben zu Cache und log drin:
Der Benchmark hierzu sieht wie folgt aus :
Ist das so richtig oder liegt ein config fehler vor ?
Zuletzt bearbeitet:
Prinzipiell ist alles richtig.
800 MB/s sync write wären ohne Optane auch gar nicht machbar.
Ein Raid-10 aus WD Platten läge bei sync write ohne Optane eher bei 50-100 MB/s.
Vielleicht mal die Optane als Slog rausnehmen und neu testen.
Das Ergebnis würde mich auch interessieren.
Was mir aber auch früher schon aufgefallen ist, ist dass sync write leicht schneller ist
als async write. Da scheint ESXi irgendwas zu tricksen/ tunen.
Ps
im ersten Screen werden nur Fehler gezeigt, hat die Optane aber nicht.
Da die Optane partitioniert ist, wird sie in der Disk-Liste nur gezeigt, wenn Partitions-Support aktiviert ist. Funktionieren tut sie unabhängig davon.
800 MB/s sync write wären ohne Optane auch gar nicht machbar.
Ein Raid-10 aus WD Platten läge bei sync write ohne Optane eher bei 50-100 MB/s.
Vielleicht mal die Optane als Slog rausnehmen und neu testen.
Das Ergebnis würde mich auch interessieren.
Was mir aber auch früher schon aufgefallen ist, ist dass sync write leicht schneller ist
als async write. Da scheint ESXi irgendwas zu tricksen/ tunen.
Ps
im ersten Screen werden nur Fehler gezeigt, hat die Optane aber nicht.
Da die Optane partitioniert ist, wird sie in der Disk-Liste nur gezeigt, wenn Partitions-Support aktiviert ist. Funktionieren tut sie unabhängig davon.
Zuletzt bearbeitet:
sollte in den recv options möglich sein, hab auch lang hier drin lesen müssen: Clarify behavior of zfs send/recv with encryption · Issue #6547 · zfsonlinux/zfs · GitHub
Die Option gibts bei Solaris leider nicht :/
CommanderBond
Enthusiast
- Mitglied seit
- 16.04.2012
- Beiträge
- 703
Unter nappit bei den autosnap jobs kann man bei den minuten nicht mehr 15;30;45 einstellen. Dort steht nur noch 15;45
Wollte grad einen Job anlegen und habe mich gewundert weil bei meinen alten jobs ging noch 15;30;45
Scheint aber nur beim erstmaligen Anlegen so zu sein. Erstellt man den Job kann man später auch wieder 15;30;45 auswählen und auch jede einzelne Minute
Wollte grad einen Job anlegen und habe mich gewundert weil bei meinen alten jobs ging noch 15;30;45
Scheint aber nur beim erstmaligen Anlegen so zu sein. Erstellt man den Job kann man später auch wieder 15;30;45 auswählen und auch jede einzelne Minute
Zuletzt bearbeitet:
