[Sammelthread] ZFS Stammtisch

ZFS Dateisysteme ist das wichtigste Menü.
Hier kann man neben SMB weitere Dienste wie NFS oder iSCSI aktivieren. Da ein ZFS Pool keine festen Partitionen kennt und jedes Dateisystem daher den kompletten Platz beanspruchen könnte, kann man das mit Reservierungen und Quotas regeln (Stichwort Speichervirtualisierung).

Dazu dann ein paar wichtige ZFS Eigenschaften wie sync (sicheres Schreiben), Compress oder Verschlüssellung
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das wichtigste/einfachste für den Einstieg aus der Windowswelt: guest=ok entweder direkt beim Anlegen des datasets oder nachträglich auf SMB Click es und den Haken setzen. (Ggf. einfach einmal SMB deaktivieren und wieder aktivieren dann mit dem Haken.)
 
ok scrub 1519003055 time: 2018.02.19.02.20.22 info:
ok scrub 1519003055 time: 2018.02.19.02.20.21 info: scrub repaired 0 in 0h0m with 0 errors on Mon Feb 19 02:20:13 2018
ok scrub 1519003055 time: 2018.02.19.02.18.20 info:
ok scrub 1519003055 time: 2018.02.19.02.18.20 info: scrub repaired 0 in 0h0m with 0 errors on Mon Feb 19 02:18:13 2018
Zum Vergrößern anklicken....

Ist es normal dass ein Scrub Job immer 2 Einträge erzeugt m Log einmal mit und einmal ohne "info" ?
 
Ja.
Der erste Eintrag zeigt einen eventuellen Fehler beim Start, der zweite das Endergebnis.
 
Achso ok :) Aber müsste dann die Reihenfolge nicht andersherum sein? Beide Einträge werden ja erst erzeugt wenn scrub durchgelaufen ist.

Würde gern ein ZFS Dateisystem auf einen anderen Pool senden, aber anscheinend kann man nur Snaps senden soweit ich durch googlen rausgefunden habe. Gibt es keine Möglichkeit ein Dateisystem mitsamt all seinen bestehenden Snaps auf einen anderen Pool zu senden?
 
Zuletzt bearbeitet:
Ich habe mir das Script angeschaut. Der erste Log ist die Rückgabe von zfs scrub, der zweite abschließende Logeintrag aus der Job Überwachung/ Fortschrittsanzeige ist überflüssig und wird entfernt.
 
Hallo,

ich habe seit heute ein seltsames Problem mit Rsync.
Hierbei kopiere ich jeden Abend die Daten auf ein NAS. Dieses hat auch bis heute funktioniert.
Warum heute? Ich habe heute die aktuellste Version von Napp-IT installiert.

Hier der Fehler:
Code: 
info: /var/web-gui/data/tools/rsync/rsync -rtu tank/Beispiel/* admin@192.168.0.60::Beispiel --password-file /etc/rsync.pwd: rsync: change_dir "/var/web-gui/data/wwwroot/cgi-bin//tank/Beispiel" failed: No such file or directory (2)

Ich habe schon probiert, den aktuellen Rsync Ordner durch den der Version 17.06 zu ersetzen, den Job neu erstellt und Napp-IT wieder auf Version 17.06 zurück gesetzt.
Keiner der Schritte hat jedoch das Problem behoben.

In der Other-Job Perl Datei habe ich auch nichts gefunden, was auf den Pfad
Code: 
/var/web-gui/data/wwwroot/cgi-bin
hinweisen würde, sobald der Job gestartet werden soll.
 
@Crash Override:

Code: 
info: /var/web-gui/data/tools/rsync/rsync -rtu tank/Beispiel/* admin@192.168.0.60:/Beispiel--password-file /etc/rsync.pwd: The --password-file option may only be used when accessing an rsync daemon.

Das seltsame ist ja, das gestern Abend um 21:00 Uhr alles noch lief.
Es muss also etwas mit dem Update von Napp-IT zutun haben.
 
XBashX schrieb:
@Crash Override:

Code: 
info: /var/web-gui/data/tools/rsync/rsync -rtu tank/Beispiel/* admin@192.168.0.60:/Beispiel--password-file /etc/rsync.pwd: The --password-file option may only be used when accessing an rsync daemon.

Das seltsame ist ja, das gestern Abend um 21:00 Uhr alles noch lief.
Es muss also etwas mit dem Update von Napp-IT zutun haben.
Zum Vergrößern anklicken....

/var/web-gui/data/tools/rsync/rsync (v 3.1.2) ist seit ca einem Jahr als Binary dabei. Damals war rsync aus dem OmniOS Repository deutlich älter. Seitdem habe ich aber daran nichts geändert. Ein direkter Zusammenhang mit einem Update ist zumindest nicht offensichtlich.

Aktuell liefert OmniOS aber rsync 3.1.3 (pkg install rsync). Man könnte das mal damit probieren (/usr/bin/rsync)
 
Auch mit dem rsync 3.1.3 tritt der selbe Fehler auf.
Stutzig macht mich der Pfad, auf den Verwiesen wird:
Code: 
 info: /usr/bin/rsync -rtu tank/Beispiel/* admin@192.168.0.60::Beispiel--password-file /etc/rsync.pwd: rsync: change_dir "/var/web-gui/data/wwwroot/cgi-bin//tank/Beispiel" failed: No such file or directory (2)
 
supemole schrieb:
Ja stimmt, aber die Zertifikate habe ich offiziell von Oracle erhalten. Die Frage ist, was gea mit 'then wait some time..' meint.
Zum Vergrößern anklicken....

Man muss sich für das Beta Repository registrieren um die Zertifikate zu erhalten und dann zusätzlich den Zugriff auf das Repository auf der Oracle Site https://pkg-register.oracle.com/ aktivieren. Dann muss man aber etwas warten (ich musste ca eine Stunde warten) bis der Zugang tatsächlich freigeschaltet wird.
 
Ich konnte mein Problem selber lösen.
Ich bin mir nicht sicher warum von heute auf morgen eine Änderung nötig war, aber es mussten vor dem Quellpfad 4x //// eingefügt werden.
Hier der abgeänderte Code:
Code: 
 /var/web-gui/data/tools/rsync/rsync -rtu ////tank/Beispiel/* admin@192.168.0.60::Beispiel--password-file /etc/rsync.pwd
 
Eigentlich kann ich bei dem verlinkten Artikel nur den Kopf schütteln.

Einerseits sind da Falschaussagen wie ZFS hätte ein 512B Default- Richtig ist dass ZFS sich danach richtet was die Platte meldet/ haben möchte. Auch werden Aussagen die nur mechanische Platten betreffen wie die 4k pyhysical Blocksize Performance Problematik wenn man die mit 512B betreibt auf SSD übertragen. Bei Platten kam das Problem auch nur dadurch, da Hersteller 4k Platten gebaut hatten die aus Kompatibilitätsgründen mit Altwindows dies nach außen verheimlicht haben. Das ist aber ein Problem von vor 5-7 Jahren. Seit vielen Jahren melden Platten ihre interne physical sectorsize korrekt.

SSD haben das nicht. Die sind in Pages und Blocks organisiert wobei ein Block z.B. 2 Mib die kleinste Einheit ist die gelöscht werden kann. Und Schreiben bei SSD (bis auf Optane, das arbeitet eher wie RAM) heißt nunmal (wenn der Block nicht frei ist) ganzen Block erst lesen, dann komplett löschen dann updaten. Eine Ausrichtung von ashift an dieser Blocksize macht aber auch keinen Sinn da ZFS seinerseits mit dynamischen Blocksizes arbeitet die zudem wenn man Compress aktiviert auch keine feste Größe mehr haben.

vgl Solid-State Drive – Thomas-Krenn-Wiki

Die eigentliche Frage ist daher. Was passiert wenn man eine Organisation der SSD erzwingt die der Hersteller nicht vorgegeben hat. Wird das dann schneller, langlebiger? Ich würde eher die Werte übernehmen die der Hersteller für die SSD vorgegeben hat sofern nicht eine ganz spezielle Überlegung etwas anderes nahelegt.
 
Zuletzt bearbeitet:
XBashX schrieb:
Auch mit dem rsync 3.1.3 tritt der selbe Fehler auf.
Stutzig macht mich der Pfad, auf den Verwiesen wird:
Code: 
 info: /usr/bin/rsync -rtu tank/Beispiel/* admin@192.168.0.60::Beispiel--password-file /etc/rsync.pwd: rsync: change_dir "/var/web-gui/data/wwwroot/cgi-bin//tank/Beispiel" failed: No such file or directory (2)
Zum Vergrößern anklicken....

XBashX schrieb:
Ich konnte mein Problem selber lösen.
Ich bin mir nicht sicher warum von heute auf morgen eine Änderung nötig war, aber es mussten vor dem Quellpfad 4x //// eingefügt werden.
Hier der abgeänderte Code:
Code: 
 /var/web-gui/data/tools/rsync/rsync -rtu ////tank/Beispiel/* admin@192.168.0.60::Beispiel--password-file /etc/rsync.pwd
Zum Vergrößern anklicken....
Deine Angabe von "/var/web-gui/data/wwwroot/cgi-bin//tank/Beispiel" kann dank des Doppelslash nicht funktionieren. Irgendwo im Script wurde an "/var/web-gui/data/wwwroot/cgi-bin" entweder ein Slash dazugeschrieben oder das wird automatisch angehängt.
 
Kann mir jemand sagen, ob ich die Snapshots in napp-it richtig konfiguriert habe? Ich hatte in der Vergangenheit das Problem, dass ich zu viele Snapshots hatte und mein Speicher recht schnell vollgelaufen ist.

Ich will - wie gea im napp-it Guide auch vorschlägt - alle 15min (behalte 4), jede Stunde (behalte 24), jeden Tag (behalte 7), jede Woche (behalte 4) und jeden Monat (behalte 24) Snapshots speichern. Ist da so richtig eingestellt?

SCREENSHOT:
snapshots.png

Ich bin mir vor allem unsicher bei Opt2/ to , also wie lange ich die einzelnen Snapshots behalten soll (in Tage).

Danke!
 
Zuletzt bearbeitet:
CommanderBond schrieb:
Okay, also ist ashift9 schon korrekt?
Zum Vergrößern anklicken....

Bis zum Beweis des Gegenteils ist das korrekt was der Hersteller für seinen SSD Controller als Default vorgibt. Der hätte vermutlich 4k oder mehr gewählt wenn das für den verwendeten SSD Controller schneller gewesen wäre. Niemand wird seine SSD künstlich bremsen wollen.

- - - Updated - - -

morumbinas schrieb:
Kann mir jemand sagen, ob ich die Snapshots in napp-it richtig konfiguriert habe? Ich hatte in der Vergangenheit das Problem, dass ich zu viele Snapshots hatte und mein Speicher recht schnell vollgelaufen ist.

Ich will - wie gea im napp-it Guide auch vorschlägt - alle 15min (behalte 4), jede Stunde (behalte 24), jeden Tag (behalte 7), jede Woche (behalte 4) und jeden Monat (behalte 24) Snapshots speichern. Ist da so richtig eingestellt?

SCREENSHOT:
Anhang anzeigen 428209

Ich bin mir vor allem unsicher bei Opt2/ to , also wie lange ich die einzelnen Snapshots behalten soll (in Tage).

Danke!
Zum Vergrößern anklicken....

Keep (Anzahl) und hold (Tage) sind zwei mögliche Werte um festzulegen wie lange oder wieviel Snaps man je Job behalten möchte. Normalerweise setzt man nur einen der beiden Werte als Limit. Setzt man beide so ergibt das eine "UND" Verknüpfung. Man muss das dann so lesen: Lösche die ältesten Snaps wenn die Mindestanzahl überschritten ist und UND diese älter sind als das Mindestalter.

Will man also nur die Anzahl limitieren, gibt man bei hold nichts ein. Man hat dann im Kurzzeitbereich viel mehr Snaps z.B. viertelstündlich in der letzte Stunde als im Langzeitbereich wo es dann für die letzten zwei Jahre nur einen Snap pro Monat gibt.
 
Zuletzt bearbeitet:
Woher kommt im Nappit Webinterface der Wert für "Usable", darunter steht zfs list aber wenn man zfs list aufruft ist kein solcher Wert zu finden. Bin etwas verwirrt wieso sich dieser Wert bei mir erhöht wenn ich eine große Datei (45GB) kopiere. Erst stand dort 2.6TB anschließend dann 2.7TB.
Der Pool ist ein mirror aus 2 HDDs. Bei einem weiteren Mirror Pool mit komprimierbaren Daten ist er sogar größer als die RAW Size.
 
Zuletzt bearbeitet:
gea schrieb:
Bis zum Beweis des Gegenteils ist das korrekt was der Hersteller für seinen SSD Controller als Default vorgibt. Der hätte vermutlich 4k oder mehr gewählt wenn das für den verwendeten SSD Controller schneller gewesen wäre. Niemand wird seine SSD künstlich bremsen wollen.
Zum Vergrößern anklicken....
Ich hab mal nach der Samsung 830 gesucht und bin über hdparm Infos Samsung SSD 830 128GB | Evil Azraels Stänkerblog gestolpert. Die SSD scheint sich wirklich nur mit 512b Sektorsize zu melden und damit wäre ashift=9 korrekt. Wenn ich mir jedoch List of sd-config-list entries for Advanced-Format drives - illumos - illumos wiki ansehe, findet sich da auch der Eintrag für dieselbe Samsung-SSD mit ashift=13.
 
CommanderBond schrieb:
Woher kommt im Nappit Webinterface der Wert für "Usable", darunter steht zfs list aber wenn man zfs list aufruft ist kein solcher Wert zu finden. Bin etwas verwirrt wieso sich dieser Wert bei mir erhöht wenn ich eine große Datei (45GB) kopiere. Erst stand dort 2.6TB anschließend dann 2.7TB.
Der Pool ist ein mirror aus 2 HDDs. Bei einem weiteren Mirror Pool mit komprimierbaren Daten ist er sogar größer als die RAW Size.
Zum Vergrößern anklicken....

zfs list pool liefert belegt und verfügbar. Total (usable) ist die Summe der beiden.
Ansonsten ist nur die Größe einer Platte exakt bekannt. Benutzt und Verfügbar sind Schätzungen aufgrund des Verschnitts aufgrund der Dateigröße und der Komprimierung. Möchte man z.B. ein Byte speichern so wird nicht 1 Byte verbraucht sondern 512B oder 4K weil das eben die Blockgröße der Platte ist. Daher liefert auch jedes Tool zum Anzeigen von belegt/verfügbar andere Werte.

Also nur als groben Richtwert sehen.

- - - Updated - - -

Stangensellerie schrieb:
Ich hab mal nach der Samsung 830 gesucht und bin über hdparm Infos Samsung SSD 830 128GB | Evil Azraels Stänkerblog gestolpert. Die SSD scheint sich wirklich nur mit 512b Sektorsize zu melden und damit wäre ashift=9 korrekt. Wenn ich mir jedoch List of sd-config-list entries for Advanced-Format drives - illumos - illumos wiki ansehe, findet sich da auch der Eintrag für dieselbe Samsung-SSD mit ashift=13.
Zum Vergrößern anklicken....

sd.conf ist keine Datei die Herstellervorgaben zeigt sondern dient dazu diese außer Kraft zu setzen also z.B. ashift=13 (8K) zu erzwingen obwohl die Herstellervorgabe ashift=9 (512B) ist.
 
Zuletzt bearbeitet:
gea schrieb:
zfs list pool liefert belegt und verfügbar. Total (usable) ist die Summe der beiden.
Ansonsten ist nur die Größe einer Platte exakt bekannt. Benutzt und Verfügbar sind Schätzungen aufgrund des Verschnitts aufgrund der Dateigröße und der Komprimierung. Möchte man z.B. ein Byte speichern so wird nicht 1 Byte verbraucht sondern 512B oder 4K weil das eben die Blockgröße der Platte ist. Daher liefert auch jedes Tool zum Anzeigen von belegt/verfügbar andere Werte.

Also nur als groben Richtwert sehen.
Zum Vergrößern anklicken....

Ich habe USED 25.1G und AVAIL 229G. USABLE wird angezeigt mit 254.1GB (RAW SIZE 238GB).

Der Pool hat FRES 23.1G also 10%. Das wird aber doch doppelt gezählt wenn man die Summe bildet. Einmal sind die FRES 23.1G schon unter USED mit dabei, und unter AVAIL sind sie auch nochmal drin. USABLE wäre damit doch um genau einmal FRES zu hoch, oder wo ist der Denkfehler?
 
Zuletzt bearbeitet:
gea schrieb:
- - - Updated - - -



sd.conf ist keine Datei die Herstellervorgaben zeigt sondern dient dazu diese außer Kraft zu setzen also z.B. ashift=13 (8K) zu erzwingen obwohl die Herstellervorgabe ashift=9 (512B) ist.
Zum Vergrößern anklicken....

Die Funktion der sd.conf ist mir klar. Mich macht der Eintrag trotzdem stutzig. Weil in meinen Augen das darauf hindeutet, daß Samsung Müll ausgibt. Spätestens wenn man diese Samsung gegen eine wesentlich grössere SSD austauscht, dürfte das mit erheblichen Performanceproblemen verbunden sein und so einfach läßt sich ja da "ashift" auch nicht mehr gerade ziehen.
 
CommanderBond schrieb:
Ich habe USED 25.1G und AVAIL 229G. USABLE wird angezeigt mit 254.1GB (RAW SIZE 238GB).

Der Pool hat FRES 23.1G also 10%. Das wird aber doch doppelt gezählt wenn man die Summe bildet. Einmal sind die FRES 23.1G schon unter USED mit dabei, und unter AVAIL sind sie auch nochmal drin. USABLE wäre damit doch um genau einmal FRES zu hoch, oder wo ist der Denkfehler?
Zum Vergrößern anklicken....

Aus Sicht des Pool Dateisystems ist 229G + 25.1G = 254.1G also korrekt.
Eine Reservierung ist da auch keine Belegung sondern nur eine Zusage dass dieser Platz in jedem Fall zur Verfügung steht/reserviert ist.

Lediglich für die anderen Dateisysteme verringert sich der zur Verfügung stehende Platz um diese Poolreservierung.

- - - Updated - - -

Stangensellerie schrieb:
Die Funktion der sd.conf ist mir klar. Mich macht der Eintrag trotzdem stutzig. Weil in meinen Augen das darauf hindeutet, daß Samsung Müll ausgibt. Spätestens wenn man diese Samsung gegen eine wesentlich grössere SSD austauscht, dürfte das mit erheblichen Performanceproblemen verbunden sein und so einfach läßt sich ja da "ashift" auch nicht mehr gerade ziehen.
Zum Vergrößern anklicken....

Die SSD gibt keinen Müll aus sondern das was Samsung aus welchen Gründen auch immer für diese SSD werksseitig festgelegt hat. Mit der sd.conf kann man das ändern, entweder weil die SSD dann vielleicht schneller sein könnte oder weil man in einem Raid einheitlich sein möchte.
 
Mit available und used passt es ja auch, nur die beiden Werte zu addieren und als "usable" zu bezeichnen ist schon verwirrend. Eigentlich hat die Summe der Werte so doch auch keinen Bezug zur Realität da durch das doppelte zählen von FRES man da sogar bei mehr als der RAW Size herauskommt.
Der Platz der da angegeben wird ist doch gar nicht "usable" in irgendeiner Form;) Die Platten sind schon vorher voll.
Ist nur meine Meinung weil ich hatte mir da letztens den Kopf zerbrochen wie das zusammenpasst und wieso der Wert höher ist. Dachte erst die Komprimierung wird da noch irgendwie reingerechnet

Würde AVAIL + ALLOC nicht sinniger sein oder einmal wieder FRES subtrahieren von AVAIL+USED ?
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Ähnliche Themen

S
LSI/Broadcom 9201-16i vs. 9300-16i vs. 9305-16i vs. 9400-16i – welcher HBA ist ideal für Proxmox + ZFS?
Antworten
6
Aufrufe
714
pwnbert
pwnbert
buzzzer
Migration Proxmox auf neue Hardware - ZFS?
Antworten
17
Aufrufe
3K
BobbyD
BobbyD
AG1M
[Kaufberatung] Neuer ZFS Homeserver
Antworten
20
Aufrufe
3K
AG1M
AG1M
E
Unraid ZFS Server 24/7 + Kaufberatung
Antworten
17
Aufrufe
2K
Elsu
E
AliManali
Sinnloser ZFS Storage
Antworten
6
Aufrufe
2K
gea
G
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