[Sammelthread] ZFS Stammtisch

Vermutlich entweder recursive Replikation in ein Dateisystem bei dem der Parent verschlüsselt ist
oder eine recursive Replikation mit Angabe der Verschlüssellung in der Art

# zfs send tank/test@snap1 | zfs recv -o encryption=on -o keyformat=passphrase -o keylocation=file:///path/to/keyfile
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hallo @gea, ich habe gerade durch Zufall (und mit Schrecken!) festgestellt, dass meine auto-jobs seit dem 13. Januar 2021 nicht mehr ausgeführt werden.
OmniOS r36
running version : 19.12b14 noncommercial homeuse
Auto jobs:
last execution:
2021.01.13.12.00.01: job 1588522741: start auto other
Davor its es zuverlässig gelaufen. Geht das noch jemandem so? Was könnte die Ursache sein bzw wie gehe ich am besten auf Fehlersuche?
 
Es betrifft aber nicht nur USB boot Gea. Offensichtlich wird die virtuelle Tastatur auch irgendwie über USB emuliert. Kurzum ich kann jetzt zwar übers Netzwerk den Bildschirm sehen, aber habe keine Tastatur.

Wenn nach dem Booten die USB Platten erkannt werden, so unterstützt Illumos zumindest den USB Chipsatz. Für die erste Bootphase ist aber der Loader zuständig. Da gibt es Unterschiede zwischen den Illumos Distributionen. OmniOS benutzt einen Port des Free-BSD Loaders. Vermutlich scheint es da ein Problem mit dieser Hardware zu geben (Ist ja kein globales Problem). Ich habe ja auch überall USB Tastaturen und nutze Remote Tastatur in ipmi. Was ich aktuell nirgends habe sind USB Bootlaufwerke.

Gibt es irgendwelche Bios Optionen zur Bootumgebung oder zum Booten wie z.B. Efi/dual oder zur USB Tastatur. Bei SuperMicro Boards gibts da teilweise einen "Windows Kompatibilitätsmodus" den ich bei früheren OmniOS Versionen mal benötigte damit die USB Tastatur beim Booten tat.
Beitrag automatisch zusammengeführt:

Hallo @gea, ich habe gerade durch Zufall (und mit Schrecken!) festgestellt, dass meine auto-jobs seit dem 13. Januar 2021 nicht mehr ausgeführt werden.
OmniOS r36
running version : 19.12b14 noncommercial homeuse
Auto jobs:
last execution:
2021.01.13.12.00.01: job 1588522741: start auto other
Davor its es zuverlässig gelaufen. Geht das noch jemandem so? Was könnte die Ursache sein bzw wie gehe ich am besten auf Fehlersuche?

Mir ist nichts bekannt. Autojob läuft bei mir mit 19.12b14 und OmniOS 151036m

AutoJob ist ein Cronjob. Was man kontrollieren kann ist ob Fehler im Cronjob einen Mail-Logeintrag erzeugt haben (cat /var/mail/root) bzw ob die Cron Warteschlange ein Problem hat (mit Consolebefehl atq).

Ansonst testhalber Autojobs erneut auf "alle 5 Minuten" stellen und Rechner mal neustarten falls irgendwo irgendwas hängt.

Ist OmniOS aktuell auf 151036m?
Mit pkg update testen ob es was neues gibt. Letzte Woche wurde ein übler Bug im Linux/Unix sudo Befehl gefixt.
 
Zuletzt bearbeitet:
AutoJob ist ein Cronjob. Was man kontrollieren kann ist ob Fehler im Cronjob einen Mail-Logeintrag erzeugt haben (cat /var/mail/root) bzw ob die Cron Warteschlange ein Problem hat (mit Consolebefehl atq).
Danke. OmniOS ist aktuell.

Es gibt aber haufenweise relevante Fehlermeldungen in /var/mail/root --- danke für den Hinweis darauf, die wurden leider nicht an meine "externe" email Adresse geschickt. Da muss ich vermutlich in /etc/aliases ergänzen "root: externe@email.adresse" ? mta ist eingerichtet.

Fehlermeldungen in /var/mail/root:

Code:
From root@omniosce Sun Jan 31 17:00:00 2021
Received: from root (uid 0) [...]
To: root
Subject: Cron <root@omniosce> perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/auto.pl
[...]
Date: Sun, 31 Jan 2021 17:00:00 +0100
Message-Id: <6016d400.41a41.4c805ea9@omniosce>
From: <root@omniosce>

Tty.c: loadable library and perl binaries are mismatched (got handshake key ff80080, needed 12400080)

Vermutlich war ich so wahnsinnig, die Perl-Module mal alle per CPAN zu aktualisieren ...? Edit: Ja, war ich. "cpan-outdated" und "cpanm --self-upgrade --sudo" Kommandos finden sich in der bash-history ...

Hättest Du einen Tipp für einen "easy fix" - rollback auf ein älteres BE und dann wieder pkg upgrade, Re-Installation napp-it, deinstallieren und reinstallieren von Perl über pkg, ...?
 
Zuletzt bearbeitet:
Die Tty Meldung bezieht sich auf das Perl Modul Expect.

Da gab es im OmniOS Update 151035f (15. Dez. 2020) ein Problem. Das ist aber in napp-it 19.12b14 behoben oder alternativ im neuesten OmniOS 151036m
 
Werde später mal meinen hpe ml10v2 testen. Der hat auch iLO. Und spuckt beim Hochfahren zumindest die selben Fehlermeldungen aus wie der gen10plus bezüglich usb Controller und kann ebenfalls nicht über usb Booten es sei denn man stellt auf usb2 um, dann gehts. Beim gen10plus gibt es so eine Option aber nicht.
Der usb Controller ist aber der vom Intel Chipsatz und beiden Fällen soweit ich weiß. Der sollte doch eigentlich unterstützt werden

installieren klappt komischerweise immer über einen usb Stick.

iso Mount beim gen10plus klappt aber auch nicht, bricht dann irgendwann ab
 
omnios ist aktuell, und auch napp-IT hatte ich vorhin per "update" reinstalliert (war schon auf 19.12b14). Wie auch immer, jetzt laufen die cron-jobs wieder - vielen Dank!
 
Habe nun omniosce-r151036 erfolgreich über ilo4 auf dem HPE ML10 v2 installieren können inklusive iso mount. Lief problemlos durch, installiert auf eine SATA SSD am Onboard SATA Controller, erster Port (der Server kann nur vom ersten Port booten ist von HPE so gemacht worden und nicht änderbar, ergo wäre später auch ein boot mirror sinnlos da er nie von einem anderen Sata Anschluss booten wird, zumindest nicht beim Onboard controller) Merkwürdig war dass ich bis lang keine Fehlermeldung mehr angezeigt bekommen habe wegen dem USB Controller obwohl im Bios USB3 aktiviert.
Ich glaube aber die kamen dort immer dann wenn ich USB Tastatur und USB Installationsmedium benutzt habe. Die einzige Meldung die dort kommt ist:

localhost rpcbind: [ID 240694 daemon.error] rpcbind terminating on signal 15

Beim HPE Microserver Gen10Plus ist aber ilo5 also eine neuere Version verbaut. Der ML10 v2 hat auch noch das "normale" Bios.


Ergo beim alten ML10 v2 mit ilo4 funktioniert es. Beim Microserver Gen10plus mit ilo5 klappt weder iso mount noch (virtuelle) Tastatur.
 
Zuletzt bearbeitet:
Ich hab meine Napp-IT-Erstinstallation jetzt seit Anfang Dezember am laufen gehabt. Im Grunde hat soweit alles funktioniert, aber aus Zeitmangel hab ich bisher immer nur den Gast-Zugang für SMB-Shares genutzt. Jetzt hab ichs mir nochmal neu installiert um nochmal mit den Berechtigungen rumspielen zu können.

Ich dachte eigentlich, dass das so schwer nicht sein kann, aber ich habs bisher nicht geschafft, mich per User/Pass an einem SMB-Share anzumelden.

Welches PDF-Dokument bzw. welche Dokumente beschreibt, wie man Berechtigungen setzt?
 
Ich dachte eigentlich, dass das so schwer nicht sein kann, aber ich habs bisher nicht geschafft, mich per User/Pass an einem SMB-Share anzumelden.

Welches PDF-Dokument bzw. welche Dokumente beschreibt, wie man Berechtigungen setzt?

Möglicherweise musst Du das Passwort des betreffenden Users nochmal setzen, da smb das separat verwaltet. Eine weitere Fehlerquelle könnte sein, dass in der /etc/pam.conf die Zeile

other password required pam_smb_passwd.so.1 nowarn

fehlt.
 
Napp-it setzt die PAM Berechtigung bei der Installation automatisch. Wird ein User per napp-it angelegt, wird auch das Passwort im Unix und Windows Format gespeichert.

Ich würde mal als erstes das root Passwort neu setzen damit man sich als root per SMB anmelden kann. Dann hat man garantiert kein Rechteproblem. Als root kann man zudem Rechte anderer User in Windows setzen (rechte Maustaste auf Ordner und Eigenschaft > Sicherheit). Solarish verhält sich mit dem ZFS/kernelbasierten SMB Service dank ntfs artiger ACL, lokalen SMB Gruppen und Windows sid von außen gesehen ziemlich exakt wie ein echter Windows Server.

In Windows dann z.B. in einem Dateibrowser unter Netzwerk "Netzlaufwerk verbinden" anklicken, dann Share eingeben z.B. \\serverip und Verbindung mit anderen Anmeldeinformation herstellen (root, pw).

Alternativ auf OmniOS den gleichen User/PW anlegen den man auch unter Windows nutzt. Dann kann man in einem Dateibroser direkt mit \\serverip zugreifen.

z.B. Oracle Manual das perfekt gut für OmniOS passt da das freie Solaris/Illumos quasi ein Fork eines frühen Solaris 11.1 darstellte, https://docs.oracle.com/cd/E26502_01/html/E29004/configuringoperationmodetm.html
 
Zuletzt bearbeitet:
PAM war in der confi file gesetzt. Das root-Pass hab ich über passwd root neu gesetzt. Ich komm jetzt aktuell nicht mal mehr aufs Wurzelverzeichnis \\ip\. Weder mit root, noch als Gast.

Ich installiere das OS samt Napp-IT nochmal neu. Meine auch Fehlermeldungen beim Durchlauf des Installscripts gesehen zu haben.

By the way: Woher kommt die Bezeichnung solarish
 
Irgendwas stimmt hier nicht. Folgendes vorgehen: Ich installiere OmniOS ( omniosce-r151036.iso ) in eine leere / neue VM und führe nach der Install folgende cli-Befehle aus, die ich mir im Dezember notiert hatte und damit bisher immer die Installation durchbekommen hab:

Code:
pkg install open-vm-tools
pkg install pkg:/package/pkg
pkg update
wget -O - www.napp-it.org/nappit | perl

Während dem Installwizzard von Napp-IT konfiguriere ich natürlich die IP, setze das root-Pass der Einfachheit halber auf "temp" und erstelle noch einen user.
Ab hier komm ich prinzipiell auf das Webinterface, was bedeutet, dass Napp-IT nach der Installation läuft. Dann kommt noch:

Code:
passwd root (anderes Passwort als temp)
passwd napp-it (neues Passwort)

Und für den Komfort gleich noch:

Code:
wget -O - www.napp-it.org/midnight_commander | perl

Grundsätzlich läuft Napp-IT dann noch und ist erreichbar über http 81.

Nach dem nächsten Reboot hat root aber wieder das passwd temp. Ich komme dann auch nicht mehr aufs Webinterface. Ich kann es jetzt nochmal mittels passwd root ändern, dann überlebt es auch den nächsten Neustart. Ein Login mit dem username napp-it und dem oben gesetzten Passwort klappt dann auch nicht mehr. Leider kenn ich das Standardpasswort vom user napp-it nicht um zu testen ob das auch wieder das initiale von der Installation ist.

Was mach ich falsch?

Edit: Ich hab das jetzt 3x mit ner nagelneuen VM probiert und es war reproduzierbar. Nach dem letzten Versuch hab ich dann einfach nochmal wget -O - www.napp-it.org/nappit | perl ausgeführt und napp-it drüber installiert, danach nochmal die Passwörtere für "root" und "napp-it" neu gesetzt. Nach einem Neustart lief dann weiterhin alles. Komisches Sache das....

Jetzt geh ich nochmal das Thema SMB-Freigabe an.
 
Zuletzt bearbeitet:
Nach dem nächsten Reboot hat root aber wieder das passwd temp. Ich komme dann auch nicht mehr aufs Webinterface.

Ich würde hier vermuten, dass in das vorherige Bootenvironment/ den vorherigen Systemstand gebootet wurde. Nach einem OmniOS Update ist daher oft sofort ein reboot fällig bevor man weiteres ändert. Nach einer napp-it Installation ist das normalerweise nicht notwendig,, kann man aber sicherheitshalber machen, alternativ mit beadm list nachschauen ob die aktuelle BE default für reboot ist (NR).

zu Solarish
Oracle Solaris ist ein Markenzeichen von Oracle nachdem die Sun gekauft haben. Ein Solaris Fork kann deshalb nicht auf Solaris verweisen, wenn es um Eigenschaften geht die sowohl für Oracle Solaris wie für die Illumos Forks (z.B. NexentaStor,OI, OmniOS, SmartOS etc) gelten. Dafür hat sich der Begriff Solarish eingebürgert (hat das was Solaris ausmacht), z.B. den ZFS/kernelbasierten SMB Server oder das Comstar FC/iSCSI Framework.

Ist ja nicht wie bei Debian oder Ubuntu die einfach sagen können wir sind Linux. Würden Illumos Distributionen sagen wir sind Solaris wäre wohl eine Abmahnung von Oracle fällig, daher Solarish
 
Zuletzt bearbeitet:
Spricht etwas dagegen einen 2. ZPool zu erstellen (weil Platten größer sind als im ersten), die Daten dann vom ersten auf den zweiten zu kopieren und den ersten am Ende abzubauen?
 
Das ist die sicherste Variante, wenn Du genug Platz und Anschlüsse hast. Auch da würde man aber vermutlich zfs send und nicht cp nutzen.
 
Gibt es eigentlich bei einem SSD pool irgendwas zu beachten bei ZFS? Also ist nen RaidZ1 Pool aus 3 oder 4 SSDs ratsam? Oder benutzt man da besser immer einen Mirror?
Überlege ob ich bei einem NAS wo ich im Grunde nur 1-2TB brauche komplett auf SSDs umzusteigen zb 3 oder 4 MX500er für reine Daten, also keine VMs. Das UBER Problem trifft ja auf SSDs nicht zu wo hier ja dann auch Raid5 bzw RaidZ1 okay wäre, oder?
 
Es kommt auf deinen Anwendungsfall an.
Bei einem stripped Mirror hast du mehr IOPS und kannst den Pool später zum Beispiel mit 2 Platten einfach erweitern.
 
Für Daten allein - um die geht es ja - genügen mE die IOPS einer SSD. Für den mirror spräche daher nur leichterer Austausch der Einzelnen SSD. Ein weiteres vdev kannst Du ja hinzufügen egal ob RAIDZ oder mirror. (Eher eine Frage des Platzes ob das Sinn ergibt)
 
Gibt es eigentlich bei einem SSD pool irgendwas zu beachten bei ZFS? Also ist nen RaidZ1 Pool aus 3 oder 4 SSDs ratsam? Oder benutzt man da besser immer einen Mirror?
Überlege ob ich bei einem NAS wo ich im Grunde nur 1-2TB brauche komplett auf SSDs umzusteigen zb 3 oder 4 MX500er für reine Daten, also keine VMs. Das UBER Problem trifft ja auf SSDs nicht zu wo hier ja dann auch Raid5 bzw RaidZ1 okay wäre, oder?

Das Problem dass in einem degraded Raid-5 jeder weitere nicht behebbare Lesefehler zu einem kompletten Array Lost führt, hat ZFS nicht. Bei ZFS Z1 ist in der gleichen Situation nicht der Pool verloren sondern nur die Datei in der der Fehler auftritt. Bei ZFS muss schon eine weitere Platte komplett ausfallen damit der Pool verloren ist.

Bei Dektop SSDs ist allerdings die Schreib Performance im Raid bei längerem Schreiben oft nicht so viel besser als bei Platten. Auch sollten SSDs ohne plp nicht für VM Storage oder Datenbanken benutzt werden. Für einen normalen Filer kann es aber dennoch deutlich was bringen. Z1 mit 3-4 SSDs ist ok, Z2 wäre sicherer bei mehr SSDs.

Ein Mirror hat mehr iops als ein Z1. Das ist aber bei SSD eher irrelevant. Selbst eine Desktop SSD hat mehrere Tausend iops während eine mechanische Platte nur ca 100 iops hat.
 
Zuletzt bearbeitet:
Ich überlege grade ob ich die RecordSize anpassen soll von 128K auf 1M für mein Dataset in dem im Grunde nur Videodateien sind von mehreren 100MB bis zu 80GB größe. Allerdings gibt es hier und da auch kleine Dateien wie zB Untertitel manchmal nur ein paar KBs groß. Würde sich die größere RecordSize dennoch lohnen?
In Nappit ist das höchste was man einstellen kann 1M. Es scheinen allerdings auch höhere Werte von ZFS unterstützt zu werden wie 4M. Warum das Limit auf 1M ?
 
In Nappit ist das höchste was man einstellen kann 1M. Es scheinen allerdings auch höhere Werte von ZFS unterstützt zu werden wie 4M. Warum das Limit auf 1M ?

Weil im aktuellen OmniOS stable/Solaris nur bis 1M unterstützt wird
siehe "man zfs" in der jeweiligen OS Version

Ich würde recordsize>1M aber eher nicht nutzen (zu neu)

Prinzipiell hat eine große recsize weniger Fragmentation zur Folge, aber eher geringere Performance für kleinere io weil auch bei kleinen Daten immer der komplette recsize block gelesen werden muss. Die voreingestellten 128k sind bereits guter Kompromiss für einen normalen Filer.

Code:
     recordsize=size
       Specifies a suggested block size for files in the file system.  This
       property is designed solely for use with database workloads that access
       files in fixed-size records.  ZFS automatically tunes block sizes
       according to internal algorithms optimized for typical access patterns.

       For databases that create very large files but access them in small
       random chunks, these algorithms may be suboptimal.  Specifying a
       recordsize greater than or equal to the record size of the database can
       result in significant performance gains.  Use of this property for
       general purpose file systems is strongly discouraged, and may adversely
       affect performance.

       The size specified must be a power of two greater than or equal to 512
       and less than or equal to 128 Kbytes.  If the large_blocks feature is
       enabled on the pool, the size may be up to 1 Mbyte.  See
       zpool-features(5) for details on ZFS feature flags.

       Changing the file system's recordsize affects only files created
       afterward; existing files are unaffected.

       This property can also be referred to by its shortened column name,
       recsize.
 
Zuletzt bearbeitet:
Bei meinem Dataset mit den mehreren GB großen Dateien seh ich aber grad nicht welchen Nachteil 1M groß hätte, auch wenn 128K ein Kompromiss sein sollte. Höchstens bei einzelnen kleinen Dateien dass die Performance da leidet. Aber bei sagen wir mal insgesamt 100 Dateien zu 2-3KB was spielt es für eine Rolle wenn sie prozentual vom Speicherplatz im Grunde irgendwo im Rauschen untergehen?
Pro Video datei hab ich vllt 1-2 solcher kleinen Dateien.
Belegt denn eine Datei die kleiner als 1M ist dann auch 1M Speicherplatz? Oder wird der Block dann auch noch für andere Daten mitgenutzt? Also wenn ich 10 Dateien a 1KB schreibe landen die dann alle im selben 1M Block oder werden 10 verschiedene benutzt?
 
Zuletzt bearbeitet:
Im Prinzip sieht es so aus.
Alle writes egal ob klein oder groß werden in RAM Writecache gesammelt und in recsize Blöcken geschrieben. Kleine Daten in kleinen Blöcken, größere in mehreren in recsize, inkl. dem letzten. Es dreht sich darum dass Copy on Write mit Snaps, compress, dedup etc auf diesen Blöcken basiert. Strukturiert eine Anwendung Daten ebenfalls in Blöcken kann es was bringen die recsize entsprechend zu setzen um unnötige reads zu vermeiden. Hat man eine Anwendung oder VM Dateisystem die sehr kleine Blöcke nutzt z.B. 4-8k so wäre eine gleich kleine recsize aber sehr ungünstig für ZFS. Daher sollte man nicht unter 32k gehen. Daher ist bei VM Storage oft 32-64k optimal. Bei großen Dateien kann eine größere recsize Performancevorteile bringen. Eine Recsize > 1M ist aber selten sinnvoll.
 
Zuletzt bearbeitet:
Hallo zusammen,

habe seit neuerem dass Problem dass die Schreibrate vom Filer (Solaris VM) auf die Clients stark einbricht.
Der HDD Pool hat 23% Speicher frei.

Folgende Werte

Solaris -> Win10PC: Von Start an 80 MB/s
Solaris -> Win10VM: Start ca 350 MB/s nach kurzer Zeit einbruch auf 80 MB/s

Storage im Server ist : 6x Seagate Ironwolf im Stripe/Mirror

Vor HW Änderungen war es im Regelfall bei ca 230 MB/s+
Es ist aktuell kein Scrub aktiv.

Änderungen

Win10PC: Asus 10 Gbit nic getauscht gegen Mellanox connect-x3 (Ethernet Modus)
Server: 100 GB Optane als Slog Device (einzel VMDK für Storage (HDD) und VM Pool (SSD))
vSphere ist auf aktuellstem Patch-Stand.

Auch das Ausschalten von Sync brachte hier (logischerweise) nichts.


1612721899764.png
 
Zuletzt bearbeitet:
Komme bei der Verschlüsselung nicht weiter.
Habe in nappit unter

"
First local keydata folder or filesystem-1 ex pool-1/keydata (L1)
Prefer an encryted filesystem or pool on an USB/iSCSI LUN
"

"keydata" eingetragen als Ordner. Es muss ja kein Dateisystem sein, steht da ja so. Also einfach nen simplen Ordner namens "keydata" erstellt auf meinem Bootlaufwerk

Allerdings wird mir nun nicht die Option beim erzeugen eines Datasets angezeigt ein Keyfile zu benutzen.

ZFS Filesystems > Encryption verweist mich wieder auf Settings man möge dort doch den Ort eintragen, was ich aber gemacht habe.
 
Komme bei der Verschlüsselung nicht weiter.
Habe in nappit unter

"
First local keydata folder or filesystem-1 ex pool-1/keydata (L1)
Prefer an encryted filesystem or pool on an USB/iSCSI LUN
"

"keydata" eingetragen als Ordner. Es muss ja kein Dateisystem sein, steht da ja so. Also einfach nen simplen Ordner namens "keydata" erstellt auf meinem Bootlaufwerk

Allerdings wird mir nun nicht die Option beim erzeugen eines Datasets angezeigt ein Keyfile zu benutzen.

ZFS Filesystems > Encryption verweist mich wieder auf Settings man möge dort doch den Ort eintragen, was ich aber gemacht habe.

Schlüssel auf rpool macht keinen Sinn. Jeder Dieb freut sich da.
Sollte schon ein Dateisystem als Basis am Besten auf einem USB Stick oder iSCSI LUN oder noch besser ein remote Webserver sein.

Mindest also z.B. datenpool/dateisystem oder datenpool/dateisystem/keydata

Hallo zusammen,

habe seit neuerem dass Problem dass die Schreibrate vom Filer (Solaris VM) auf die Clients stark einbricht.
Der HDD Pool hat 23% Speicher frei.

Folgende Werte

Solaris -> Win10PC: Von Start an 80 MB/s
Solaris -> Win10VM: Start ca 350 MB/s nach kurzer Zeit einbruch auf 80 MB/s

Storage im Server ist : 6x Seagate Ironwolf im Stripe/Mirror

Vor HW Änderungen war es im Regelfall bei ca 230 MB/s+
Es ist aktuell kein Scrub aktiv.

Änderungen

Win10PC: Asus 10 Gbit nic getauscht gegen Mellanox connect-x3 (Ethernet Modus)
Server: 100 GB Optane als Slog Device (einzel VMDK für Storage (HDD) und VM Pool (SSD))
vSphere ist auf aktuellstem Patch-Stand.

Auch das Ausschalten von Sync brachte hier (logischerweise) nichts.


Anhang anzeigen 587369

Die Pool Werte sind ja genial. 360 MB/s sync und 1200 MB/s ohne sync bei dreifach Platten-Mirror. Auch die read Werte sind extrem gut.

Solaris mit Original ZFS ist oft der schnelleste ZFS Server, 1200 MB/s bedeutet aber dass die schwächste aller Platten 400 MB/s schreibend kann. Da hilft der ZFS RAM Schreibcache sicher mit, so schnell ist keine Ironwolf Platte.

Wichtiger ist aber: Die Änderung ist Clientseitig. Da kann man serverseits nichts optimieren. Eventuell nach einem neueren Windows Treiber suchen oder an den Treiber Einstellungen drehen. Int Throttelling=0ff ist z.B. bei Intel nics eine besonders wichtige Einstellung für high Performance.
 
Zuletzt bearbeitet:
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