[Sammelthread] ZFS Stammtisch

Erklärt aber nicht wieso es nicht geht weil da steht Folder und hab einen angelegt. Was funktioniert denn jetzt und was nicht?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
mit einem dataset als source scheint es zu klappen. Wieso wird eigentlich passphrase benutzt? ZFS bietet hier doch auch RAW und HEX an was für ein KeyFile doch näherliegend wäre?

Bei einem umbenennen des Datasets muss man allerdings das Keyfile manuell umbenennen sonst findet er es anschließend nicht mehr.

Und kann ich ein Encryptes Dataset mit Passphraseeingabe auch noch irgendwie "umbiegen" nach "Keyfile" hin? So wie ich das sehe muss ich ja nur den Key splitten in 2 Teile, 2 Dateien erstellen mit dem richtigen Namen und die in den passenden Keydata Ordner packen und dann noch paar Eigenschaften beim Dataset verändern? Aber welche genau?

edit:

schon selber hinbekommen, indem ich einfach den Key gesplittet habe und in 2 Dateien gepackt habe und
keylocation=prompt und enc_split:=L1:L1 gesetzt habe.
So wie ich das sehe sollte der Pool und Dataset dann ja auch unter FreeNAS beispielsweise zum laufen gebracht werden können weil man die Passphrase dort einfach direkt eingeben kann ?
 
Zuletzt bearbeitet:
Hi,

habe irgendwie ein komisches Phänomen, was ich mich aktuell nicht so Recht erklären kann.

Ich lasse einmal monatlich einen scrub über meinen pool per napp-it job laufen, soweit so gut.
aber offenbar bekomme ich jedes mal kurz nachdem der scrub gestartet wurde (1min) eine Alarm Meldung
von napp-it beüzüglich disk-error.

1612782835337.png


Demnach "soll" der mirror-0 offline sein, obwohl aber beide vdevs online sind. Weiß nicht so
Recht, was das bedeuten soll. Irgendjemand 'ne Idee was das soll?


Code:
-disk errors:
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0 in 1m12s with 0 errors on Sun Jan 31 22:01:14 2021

config:

        NAME      STATE      READ WRITE CKSUM
        rpool     ONLINE        0     0     0
          c3t0d0  ONLINE        0     0     0

errors: No known data errors

  pool: storage
 state: OFFLINE
  scan: scrub repaired 0 in 10h19m with 0 errors on Tue Feb  2 13:20:42 2021

config:

        NAME                       STATE      READ WRITE CKSUM
        storage                    OFFLINE       0     0     0
          mirror-0                 OFFLINE       0     0     0
            c0t5000CCA291E18BABd0  ONLINE        0     0     0
            c0t5000CCA291E15EC2d0  ONLINE        0     0     0
        logs
          c3t1d0                   ONLINE        0     0     0

errors: No known data errors
 

Anhänge

  • 1612782796681.png
    1612782796681.png
    2 KB · Aufrufe: 82
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.

Was ich vergessen hatte, mit der Optane am Server hab ich den vSphere 7.x neu installiert auf die Optane um vom Boot USB Stick weg zu kommen.
Find es merkwürdig, das wenn ich mich im vSphere Netz bewege also nur vSphere intern Solaris wie auch Win10 Pro VM hat jeweils das selbe Netz und die VMXNET3 (10G).
Somit darf doch keiner meiner Hardware switches Involviert sein. Oder ist mein Denkansatz falsch?
Ein TrafficShaping ist nicht aktiv auf dem vSwitch.
Könnte später mal testen n neues Netz anzulegen / solaris / VM neue Adapter zu geben.

Solaris hab ich die VMware Tools nochmals drüber installiert / keine Änderung.

Für den Fall das es errforderlich wird, wie kann man am leichtesten das SLOG Device entfernen? Bzw. was wäre zu bedenken? So kann ich mir das schon mal dokumentieren.
 
Wieso ziehen Berechtigungen bei Napp-IT erst nach einem Neuaufbau der SMB-Verbindung?

Folgendes: Ich hab es soweit geschafft, dass ich mit meinem Windows-Client über den root-User Rechte verteilen kann. Jetzt bin ich gerade dabei, die Rechte zu verfeinern. Dabei hab ich folgendes Problem:

Ich habe auf \\ip\pool\dataset\folder und _alle_ Unterverzeichnisse Leserechte für die Gruppe "Group1" vergeben.

Dann habe ich für den Ordner subfolder ( \\ip\pool\dataset\folder\subfolder ) die Rechte für Group1 entzogen. Damit man in "subfolder" rein kommt, hab ich Group2 definiert und subfolder sowieso dessen Inhalt nur Group2 berechtigt. subfolder selbst hat also keine Berechtigung mehr durch Group1, aber durch Group2.

Nun hab ich mich mit einem Nutzer "test" (Mitglied von Group1) am SMB-share angemeldet. Ich konnte also "subfolder" nicht sehen. Während der aktiven SMB-Session hab ich im Napp-IT Interface den user "test" auch zu Group2 hinzugefügt. Ich konnte "subfolder" unmittelbar danach aber nicht sehen. Ich musste erst den Windows-Client neustarten, um "subfolder" sehen zu können. Vor dem Neustart hab ich direkt versucht, den kompletten Pfad in die Adressleiste vom Explorer einzutippen, aber das hat nichts gebracht.

Umgekehrt ist es so: Wenn user zum Zeitpunkt des Aufbaus der SMB-Verbindung in Group1 und Group2 ist verbindet, kann er den Ordner subfolder ja sehen. Lösche ich user aber während der Session aus Group 2, hat er weiterhin Zugriff auf subfolder und kann darin auch Dateien öffnen. Erst nach einem Neustart des Windows-Clients war "subfolder" nicht mehr in folder sichtbar.


Zur Info:
Group1 wie auch Group2 haben angehakt:
Vereinfachte Rechte: Lesen
Erweiterte Rechte: Ordner auflisten / Daten lesen ; Attribute lesen ; Erweirterte Attribute lesen ; Berechtigungen lesen

Für die Rechtevergabe hab ich eine eigens dafür installiert Win7-VM, die immer mit root am smb-share hängt. Für den Test der Berechtigungen hab ich eine eigens dafür installierte Win7-VM, die auf schnelle Reboots optimiert ist.

(Ich weiß, dass ich alternativ zu einem Neustart auch einfach net use * /delete nutzen könnte, um die SMB-Session zu schließen, aber das ist nicht immer so zuverlässig wie Neustart / re-login. Dummes Windows eben...)
 
Zuletzt bearbeitet:
Im Prinzip verhält sich Solarish hier wie Windows. Geänderte Datei-ACL werden sofort wirksam, Gruppen und User-Änderungen erst nach einem Logout/Login (oder SMB Service restart). Die erweiterten ntfs ACL, lokale SMB Gruppen und Vererbung werden von Solarish voll unterstützt. Lediglich deny Regeln sollten nicht aus Windows sondern in Solarish gesetzt werden da Windows zuerst deny Regeln beachtet während Solarish die Reihenfolge der Regeln beachtet (wie bei einer Firewall). Die Reihenfolge der ACL kann man aus Windows nicht beeinflussen.

ps
Wenn man möchte das z.B. alle einen Ordner öffnen können, nicht aber Unterordner, so setzt man nur auf diesen Ordner Lese (opt. Create) Rechte (erweiterte Rechte: Nur diesen Ordner) für alle. Wenn man für die tieferliegende Ordner abweichende Rechte setzt kann man diese weiter vererben (Ordner und enthaltene Ordner). Mit der Sharing Option ABE kann man dafür sorgen, dass Ordner auf die man keine Rechte hat, nicht gezeigt werden.
 
Zuletzt bearbeitet:
Moin Zusammen,
habt ihr empfehlungen für kostenlose Software oder andere Lösungen, womit ich mir selbst visualisieren kann wie mein Datei und Backupmanagement aufgeteilt ist?
Grund ist, dass ich (für mich pers.) viele HDDs und SSDs im Server, Workstation, NAS sowie div. USB Backup HDDs am laufen habe.
Workstation 2xHDDs, 4x SSDs,
Server 3x HDDs, 1x SSD
NAS 4xHDD
USB 4x HDD
Ich blicke mittlerweile aber echt nicht mehr wirklich durch wo welche Daten liegen und welche Backuplayer wann an der Reihe sind.
Da ist es in der Firma wesentlich strukturierter :d
 
Ordnung und Struktur schaffen und nichts kompliziert machen.

Lokal braucht man nur eine Bootplatte, Programme und keine Daten.
Die Daten sind alle auf dem ZFS NAS mit vielen Snaps, damit viel sicherer und mit Versionierung. Braucht man "lokale" Platten, die vom NAS per iSCSI beziehen.

Die Dateisysteme des ZFS NAS werden auf ein zweites NAS in einem anderen Brandabschnitt oder ein oder zwei wechselnde abnehmbare externe Pools (usb, backplane etc) repliziert.
 
Lokal braucht man [...] keine Daten.
Naja wenn du Performance brauchst (4k Videoschnitt, Bildbearbeitung) hat man die Daten gerne auf einer nvme liegen ;)
Muss dazu gestehen das ich kein ZFS nutze, dachte nur ihr habt hier gute Ideen dazu.
Dann nehm ich mal mein Anliegen und ziehe davon :d
 
Naja wenn du Performance brauchst (4k Videoschnitt, Bildbearbeitung) hat man die Daten gerne auf einer nvme liegen ;)
Muss dazu gestehen das ich kein ZFS nutze, dachte nur ihr habt hier gute Ideen dazu.
Dann nehm ich mal mein Anliegen und ziehe davon :d

Das sind allenfalls Arbeitsdaten die man nur kurzfristig braucht und die man daher nicht unbedingt sichern muss. Normalerweise ist man aber auch bei 4k Video mit Datenraten ab 500 MB/s gut dabei um in Echtzeit abzuspielen und das ist bei 10G Netzwerk und erst Recht für ein gutes NAS kein Problem - nicht mal für ZFS das ja einige Resourcen wegen überragender Datensicherheit benötigt.

Ideal ist schon: Ein Ort für Daten, Versionierung z.B. per Windows vorherige Version (letzte Viertelstunde. letzte Stunden aktueller Tag, je Tag diese Woche, je erster am Monat etc) und im Notfall ein Backupsystem mit eigener Versionierung.
 
Danke, sollte ich mich dem Thema mal annehmen werde ich gerne darauf zurückkommen.
Da mein Server aktuell aber echt schwach ist (i3 4130, 24GB non ECC, 1Gbit Netzwerk etc.) und erstmal keine Neuanschaffung ansteht wird das noch etwas dauern.
 
Würde wohl schon reichen da 10G einzubauen (gibts auch billig in der Bucht), eventuell da einen NVMe Pool.
Ansonst Arbeitsdaten lokal und Dauerdaten mit Snaps auf dem NAS.

Selbst 1G ist da nicht so das Problem, selbst mit 4k. Performance braucht man da ja lediglich um unkomprimierte Daten in Echtzeit abzuspielen. Snap als erste Sicherung und Backup des Dateisystems mit Snaps ist da das Schlüsselthema.

ps
Dies ist der ZFS Thread. Wir diskutieren state of the art Datensicherheit, Versionierung und Backup.
 
Ich kopiere grad Sachen mit Windows 10 von einem Server auf den anderen. Beide OmniOS. Bei einer Datei, Größe etwa 20GB, stürzt aber jedesmal der Explorer ab und startet sich neu während des Kopiervorgangs. Die beiden Pools melden allerdings keine Checksummenfehler. Hat jemand ne Idee wieso und weshalb? Hab grad mal mittels FileHashChecker meine Quelldatei überprüft. Lässt sich vollständig lesen.
 
Zuletzt bearbeitet:
Klappt das wenn man erst die Datei lokal herunterkopiert and dann auf den anderen Server?
Macht die Server SMB Version einen Unterschied (serverseits OmniOS 151036 bis SMB 3.1.1, ältere 3.0 oder 2.1)?
Klappt das bei einem anderen Windows Client (andere nic, andere Windows Version)
macht ein testweises Umstellen von nbmand (zfs Eigenschaft) oder oplock (SMB Eigenschaft) einen Unterschied?
 
Ich habe mal einen anderen Client genommen. Dort scheint es jetzt zu klappen, schließe den Fehler auf Serverseite dann mal aus.
Kopiere grade von einem Dataset daten in ein anderes vom selben Pool 4x 14TB RaidZ2 *kein SMR, beide verschlüsselt.
Geschwindigkeit ist 30-40MB/s, wobei eher 30, mit 16GB Ram und QuadCore 4x3,4Ghz und AES-NI. Kommt mir irgendwie etwas sehr langsam vor, auch wenn er Lesen und Schreiben von den selben Platten muss.
Beim reinen Lesen auf einen Client lande ich auch maximal so um die 60-80MB/s, trotz dieser Hardware. Dachte mit dieser Hardware wäre es endlich mal möglich einen Gbit Link auszulasten...
Selbst bei SSDs habe ich Gbit noch nie ausgelastet gesehen im Zusammenhang mit ZFS. Ich weiß nicht ob ich da einfach "Pech" habe? Fragmentierung des Pools steht auch bei 0%
Ein Scrub liefert aber zumindest "gescheite" Readwerte. iperf kommt auf 800-900mbit. Eine direkt Verbindung zwischen Client und Server ändert auch nichts am Ergebnis.

Disk IO zeigt bei den einzelnen Festplatten auch %b unter 20 an.
 
Zuletzt bearbeitet:
Ich habe mal einen anderen Client genommen. Dort scheint es jetzt zu klappen, schließe den Fehler auf Serverseite dann mal aus.
Kopiere grade von einem Dataset daten in ein anderes vom selben Pool 4x 14TB RaidZ2 *kein SMR, beide verschlüsselt.
Geschwindigkeit ist 30-40MB/s, wobei eher 30, mit 16GB Ram und QuadCore 4x3,4Ghz und AES-NI. Kommt mir irgendwie etwas sehr langsam vor, auch wenn er Lesen und Schreiben von den selben Platten muss.
Beim reinen Lesen auf einen Client lande ich auch maximal so um die 60-80MB/s, trotz dieser Hardware. Dachte mit dieser Hardware wäre es endlich mal möglich einen Gbit Link auszulasten...
Selbst bei SSDs habe ich Gbit noch nie ausgelastet gesehen im Zusammenhang mit ZFS. Ich weiß nicht ob ich da einfach "Pech" habe? Fragmentierung des Pools steht auch bei 0%
Ein Scrub liefert aber zumindest "gescheite" Readwerte. iperf kommt auf 800-900mbit. Eine direkt Verbindung zwischen Client und Server ändert auch nichts am Ergebnis.

Disk IO zeigt bei den einzelnen Festplatten auch %b unter 20 an.

20% busy zeigt an dass der Pool nicht ausgelastet ist und mehr könnte.
Ob das Problem eher clientseitig (Windows, Lan) oder serverseits (Verschlüssellung) liegt, kann man mit zwei Test ermitteln

1. Pool > Benchmark laufen lassen, mit und ohne Verschlüssellung
Der Test läuft mit und ohne sync. Sync Werte zeigen gut die io Leistung, sequentiell Schreiben die allgemeine Leistung

2. Lokal Midnight Commander starten und ein großes File z.B. video oder OmniOS iso von einem (verschlüsselten) Verzeichnis in ein anderes kopieren. Dabei wird die Performance beim lokalen Kopieren gezeigt. Will man Cache Effekte ausschließen, vor dem Test rebooten.
 
Moin, es gab hier doch mal eine Diskussion um die optimale Anzahl an HDD im Raidz2. Finde ich nicht mehr. Überlege gerade ob 6x12 TB im Raidz2 ok ist, oder ob 7x12TB Vorteile bringt.
 
20% busy zeigt an dass der Pool nicht ausgelastet ist und mehr könnte.
Ob das Problem eher clientseitig (Windows, Lan) oder serverseits (Verschlüssellung) liegt, kann man mit zwei Test ermitteln

1. Pool > Benchmark laufen lassen, mit und ohne Verschlüssellung
Der Test läuft mit und ohne sync. Sync Werte zeigen gut die io Leistung, sequentiell Schreiben die allgemeine Leistung

2. Lokal Midnight Commander starten und ein großes File z.B. video oder OmniOS iso von einem (verschlüsselten) Verzeichnis in ein anderes kopieren. Dabei wird die Performance beim lokalen Kopieren gezeigt. Will man Cache Effekte ausschließen, vor dem Test rebooten.
Werde ich mal machen. Allerdings hab ich schon wieder ein weiteres Problem. Nach einem längeren Kopiervorgang berühigt sich der Pool gar nicht mehr, auch wenn dieser schon seit Stunden abgeschlossen ist. Die Platten rattern weiterhin vor sich hin wie bei irgendwelchen Random Zugriffen. Hab selbst SMB deaktiviert und sogar das Netzwerkkabel getrennt, aber der Pool ist weiterhin busy.
Fehler werden keine gemeldet irgendwo. . Auf dem Pool sind nur ein paar Datasets die per SMB freigegeben sind. Sonst nichts was irgendwie Zugriff verursachen könnte. Wie kann ich herausbekommen wer oder was da am schreiben/lesen ist?
Auch ein Neustart behebt das Problem nicht.
Ein "warmer" neustart lässt die HDD auch während des bootens weiterhin rödeln.
Unterbrechen der Stromzufuhr und hochfahren lässt die HDDs zwar leise sein während des Bootens, doch wenn das System hochgefahren ist sind die ständigen Zugriffe wieder da.

fsstat: operations per filesystem or service per s
"zfs" zeigt im Leerlauf mit keinem über SMB freigegebenen Dateisystem und keinen Entschlüsselten Dateisystem lookup bzw rdir ops an zwischen 10k bis 25k im absoluten Leerlauf, teilweise sogar bis zu 50k und mehr im Peak. read ops auch ein wenig

Es gibt keine VMs oder sonstiges auf dem System.

edit:


Habe nun aber erstmals stabile 100-110MB/s schreiben über SMB auf dem Server erreicht, Datei >20GB. Kein Unterschied festzustellen ob das Dataset verschlüsselt war oder nicht.
Lesen hingegen ist deutlich langsammer und instabiler von der Geschwindigkeit her sowohl verschlüsselt als auch unverschlüsselt. 50-80MB/s. Auf der Clientseite ein Raid0 aus 2mal 4TB HDDs benutzt welcher nur zum testen erstellt wurde, dh komplett leer ist/war um dort einen Flaschenhals auszuschließen.

Intersanterweise ist Lesenschreiben, also eine Datei im selben Verzeichnis zu kopieren nur etwas langsammer als schreiben, auch in etwa 100MB/s. Sogar schneller als nur Lesen in meinem Fall.

Grad nochmal probiert eine Datei von einem Dataset (128K,verschlüsselt) in ein anderes zu kopieren (1M, verschlüsselt), auf dem selben Pool, hier bricht Lesenschreiben dann ein auf 30-40MB/s. Obs daran liegt dass es 2 verschiedene Dateisysteme sind oder weil die recordsize verschieden ist weiß ich nicht. Dazu müsste ich nochmal 128K=>128K und 1M =>1M testen, weiß noch nicht ob ich das noch mache.

Im Leerlauf, rattern die Festplatten aber weiterhin vor sich hin. Beim Lesen bzw Schreiben sind sie sogar weniger laut warscheinlich weil dort weniger Random Zugriffe stattfinden.
Der Pool hat übrigens ein Füllstand von 89%. Die Lesenschreibenwerte waren aber bei unter 50% schon genauso mies zwischen den 2 Datasets. Der Füllstand erklärt in meinen Augen aber nicht die ständigen Zugriffe, genauso wenig wieso Lesen langsamer ist als Schreiben und Lesenschreiben.
 
Zuletzt bearbeitet:
Ein Füllstand von 89% erklärt eine niedrigere Performance da dann die Fragmentierung stark zunimmt.

Wenn man starke Plattenaktivität selbst bei abgezogenem Netwerkkabel sieht, sehe ich als Hauptverursacher einen Scrub (siehe Menü Pools) oder z.B. einen long Test der Smartmontools. Mit Netz müsste man schauen ob ein Client Aktivität erzeugt z.B. auch durch einen Indexlauf.

In napp-it kann Echtzeitmonitoring oder Hintergrund Acceleration Last erzeugen, zumindest eine Zeitlang nach dem letzten Zugriff. Probehalber im Topmenü neben Logout "acc" und "mon" deaktivieren. Auch Menü Jobs kontrollieren ob da jobs laufen, eventuell Autojobs deaktivieren.

Was man noch beobachten kann ist ob die Last auf allen Platten ähnlich ist z.B. %wait oder %busy. Da die schlechteste die Performance bestimmt, kann ein starker Unterschied eine schwache Festplatte bedeuten.
 
Ein Füllstand von 89% erklärt eine niedrigere Performance da dann die Fragmentierung stark zunimmt.
Die Fragmentierung ist bei 1% laut properties. Da ich aber im Grunde nur große Files rüber kopiert habe und 1M recordsize fällt es mir schwer hier die Fragmentierung als Ursache zu sehen. Obendrein sind die Schreibwerte ja weiterhin hoch. Es ist auch nicht so dass der pool "alt" ist.

acc und mon deaktivieren bringt keine Veränderung.
 
Die Angabe der Fragmentierung bezieht sich nicht auf den Pool sondern auf den freien Bereich, Eine große Recordsize bei fast vollen Pools kann dann sogar verlangsamend wirken weil immer weniger große freie Blöcke zur Verfügung stehen und die Köpfe mehr springen müssen.

Hinzukommt dass der Ramcache beim Schreiben volle Wirkung zeigt während beim Lesen keine sequentiellen Daten im Arc Cache liegen.
 
Und bei kleineren Blöcken müssen sie mitunter aber häufiger springen. So oder so würde das maximal wenn überhaupt niedrigere Leistung erklären, aber nicht wieso ich random Zugriffe im völligen Idle habe... Es gibt auch nicht einen Job, da ist einfach nichts. Nur omnios installiert plus nappit und user angelegt und daten rüber kopiert..
Und wie gesagt der Pool wurde quasi in eins mit großen Dateien gefüllt. Wo soll die fragmentierung herkommen wenn zfs die Daten nicht absichtlich grad so verteilt dass hohe fragmentierung entsteht. Wie gesagt das ist kein Pool der jetzt 5Jahre alt ist und wo zig Dinge im Verlauf der Zeit gelöscht, neuerstellt oder verändert wurden.
So oder so war die Performance bei 50% jetzt auch einfach nicht besser.
Unter iostat habe ich über pool2 ein Gerät mit dem Namen ".FDF5d0" weiß aber nichts damit anzufangen.

Mit einer Auslastung von 61% ist von den Zugriffen nun nichts mehr zu hören. Die Fragmentierung steht jetzt übrigens wieder auf 0%. Der Zusammenhang ist mir aber weiterhin unklar. Also wird der Pool mit höherem Füllstand auch LAUTER ?
An der Performance hat sich allerdings nicht geändert, die Lesewerte sind immer noch unter den Schreibwerten.
Ramcache: Ich habe 16GB Ram. Wenn dies die Ursache für hohe Schreibwerte ist könnte ich auch einfach mal eine 50 oder 90GB Datei übertragen. Die Geschwindigkeit müsste dann ja wenn der Ram voll ist einbrechen...
 
Zuletzt bearbeitet:
Ich beantworte meine Frage mal selbst, habe es doch gefunden:
4, 6,10 sind wohl die optimalen Anzahlen an HDD für Raidz2

Ist eigentlich überholt. Wenn man was man häufig macht LZ4 aktiviert dann gilt das gar nicht mehr weil die Blockgröße nach Komprimierung variabel ist. Ohne compress hat man etwas mehr "Datenverschnitt" wenn die Anzahl der Datenplatten nicht im Raster 2,4,816 liegt.
Beitrag automatisch zusammengeführt:

Und bei kleineren Blöcken müssen sie mitunter aber häufiger springen. So oder so würde das maximal wenn überhaupt niedrigere Leistung erklären, aber nicht wieso ich random Zugriffe im völligen Idle habe... Es gibt auch nicht einen Job, da ist einfach nichts. Nur omnios installiert plus nappit und user angelegt und daten rüber kopiert..
Und wie gesagt der Pool wurde quasi in eins mit großen Dateien gefüllt. Wo soll die fragmentierung herkommen wenn zfs die Daten nicht absichtlich grad so verteilt dass hohe fragmentierung entsteht. Wie gesagt das ist kein Pool der jetzt 5Jahre alt ist und wo zig Dinge im Verlauf der Zeit gelöscht, neuerstellt oder verändert wurden.
So oder so war die Performance bei 50% jetzt auch einfach nicht besser.
Unter iostat habe ich über pool2 ein Gerät mit dem Namen ".FDF5d0" weiß aber nichts damit anzufangen.

Mit einer Auslastung von 61% ist von den Zugriffen nun nichts mehr zu hören. Die Fragmentierung steht jetzt übrigens wieder auf 0%. Der Zusammenhang ist mir aber weiterhin unklar. Also wird der Pool mit höherem Füllstand auch LAUTER ?
An der Performance hat sich allerdings nicht geändert, die Lesewerte sind immer noch unter den Schreibwerten.
Ramcache: Ich habe 16GB Ram. Wenn dies die Ursache für hohe Schreibwerte ist könnte ich auch einfach mal eine 50 oder 90GB Datei übertragen. Die Geschwindigkeit müsste dann ja wenn der Ram voll ist einbrechen...

ZFS Raid verteilt die Daten ziemlich gleichmäßig über die vdevs, Es gibt daher kein rein sequentielles Verhalten bei dem Spur um Spur aufgefüllt wird. Zusammen mit Copy on Write bei dem Datenblöcke ja nicht geändert werden sondern immer neu erstellt hat ZFS grundsätzlich eine höhere Fragmentierung als ältere Dateisysteme. Wenn der Pool voll wird gibt es immer weniger große freie Blöcke. Dass ein kleiner Block dann näher liegt ist wahrscheinlicher. Ein fast voller Pool kann dann tatsächlich lauter sein (mehr Kopfbewegungen)

Langsamer Lesen als Schreiben ist nicht so ungewöhnlich bei sequentieller Last

Der Schreibcache cacht keine Dateien. Wenn er halb voll ist werden die darin enthaltenen Dateien in Blöcke in recsize aufgeteilt (kleine Dateien in kleinerem Block) und auf den Pool geschrieben. Die andere Hälfte des Caches übernimmt dann die Pufferfunktion. Sinn ist vor allem das Schreiben kleiner Blöcke zu vermeiden.

Sieht man gut wenn man einen Plattentest wie Atto ansieht. Bei Datenblöcken bis ca 128k ist die Performance mies, bei 4-16k sogar unterirdisch schlecht. Ab 128k wird es sehr schnell sehr viel besser. Ein guter ZFS Pool hat ja eine Schreibperformance von mehreren Hundert MB/s. Da brauchts dann keine Cache Unterstützung mehr wenn keine kleinen Blöcke kommen,
 
Zuletzt bearbeitet:
Ist eigentlich überholt. Wenn man was man häufig macht LZ4 aktiviert dann gilt das gar nicht mehr weil die Blockgröße nach Komprimierung variabel ist. Ohne compress hat man etwas mehr "Datenverschnitt" wenn die Anzahl der Datenplatten nicht im Raster 2,4,816 liegt.
Hake hier mal kurz ein:
Also würdest du empfehlen lz4 zu aktivieren? Wird dies dann auch auf bereits geschriebene Daten angewandt oder nur auf neu geschriebene?
 
Hake hier mal kurz ein:
Also würdest du empfehlen lz4 zu aktivieren? Wird dies dann auch auf bereits geschriebene Daten angewandt oder nur auf neu geschriebene?

In der überwiegenden Anzahl der Fälle wird ZFS mit lz4 schneller und Daten brauchen weniger Platz. Allenfalls bei Ultra High Performance Anforderungen oder ganz lahmer CPU und bei sehr schlecht komprimierbaren Daten würde ich lz4 ausschalten sonst immer an.

Compress wirkt nur bei neu geschriebenen Daten nachdem man das aktiviert hat.
 
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