[Sammelthread] ZFS Stammtisch

Wieso stellt NappIT die Systemzeit falsch ein?

Habe im Bios die Uhr nach UTC eingestellt (aktuell 16Uhr). In Nappit dann auch alles für Deutschland richtig eingestellt (Europe / Berlin) aber da zeigt er mir ebenfalls 16Uhr an. Eigentlich müsste aber doch eine Stunde aufaddiert werden.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das klappt nur, wenn man eine UTC Zeit als Referenz hat und nicht eine absolute Bios Zeit, z.B.
wenn man in napp-it per "other job" die Zeit mit einem ntp Server abgleicht.

Wenn man den job z.B. täglich laufen lässt, stimmt die Uhr immer
 
Wider deiner Vermutung ist es doch für den Privatgebrauch ;)
Eine konkrete Zielkapazität schwebt mir nicht vor, aktuell schaffe ich es immer wieder mich mehr schlecht als recht mit meinen 2 RAID 6 mit ~ 10TB Nettokapazität durchzuschlagen. Die Grenzen dieses Systems sind bald erreicht und ich überlege eh schon seit einiger Zeit eine sinnvolle Ablöse zu finden die dann halt auch wieder für längere Zeit vorhält bzw. leicht erweiterbar ist. Beim alten System habe ich leider zu wenig auf diese Aspekte geachtet :(
Ich denke eine doppelte Kapazität des jetzigen Systems wäre schon toll, dann hätte ich die nächsten Jahre genug Reserven (auch hinsichtlich 4K etc).

Gehäuse ist nur ein alter Desktop-Tower vorhanden, mir würde aber ein Inter-Tech 4U-4324L in den Sinn kommen. Performance ist nicht so wichtig, wenn es für sag ich mal 1-5 Leute die Daten übers Netz bereitstellen kann ist es okay. Aber gerade weil es für den Privatgebrauch ist möchte ich halt auch die größtmögliche Kapazität mit einem vertretbaren Verbrauch für Parität haben.

Die Frage mit dem Kaufen ist natürlich auch sehr interessant, das wird eine Herausforderung bzw. werde ich da wohl eher dem Zufall vertrauen müssen.

Du solltest dir vorher klar werden,
- welchen Raid-z-Level du haben willst,
- dann wieviel vdevs pro pool,
- ob du den Pool mit ashift=9 oder ashift=12 anlegen willst,
- dann erst kannst du die Anzahl der HDDs pro vDev festlegen,
um so wenig wie möglich Verluste zu haben.

Wenn ich es zwischen den Zeilen richtig verstehe, bestehen die Daten meistens aus Multimedia-Inhalten - da reicht IMHO Raid-Z2, pack lieber eine Hot-Spare mit rein,
dann sollen bis zu 5 Leuten im LAN (nicht per WAN) drauf zugreifen (streamen) können - da wird ein vDev vermutlich zu wenig sein, also Zwei. Mehr wird nichts bringen, da dann deine Netzwerkkarte der Flaschenhals ist.
Ich persönlich halte nichts davon verschiedene HDD-Hersteller zu mischen, Ein Hersteller, ein HDD-Modell - dann aber bei verschiedenen Händlern zu verschiedenen Zeiten kaufen. Ich nimm seit Jahren nur noch Hitachi jetzt HGST und hab nur eine einzige defekte HDD (Garantie) bisher gehabt. Die Jungs bei Backplaze haben mal eine Auswertung gemacht, welche Platten von welchem Hersteller am Wenigsten hinüber gehen. Such mal im Netz danach.
In jedem Falle eine kleine USV dranhängen, damit Überspannungen und kurze Stromausfälle abgefangen werden können.
6 TB Platten sind schon der Hammer, würde ich aber noch nicht nehmen - oder hast du im Netz etwas gefunden, wie vibrationsstabil die 6TB Dinger sind - bei 24 HDD im Case da vibriert es ganz schön.

4k --> da gibts doch noch gar nichts um auf Platte speichern - also Original nichts geshrinktes, falls doch schick mal bitte eine PN.

ZFS und RaidZ ist schon geil, aber einen Backup-Server würde ich mit den alten HDDs in jedem Falle zusammenbauen. Mein Backupserver besteht aus einem vdev mit 18 HDDs als RaidZ2 (+ eine Coldspare) = 28TB nutzbar(siehe Footer). Ein Mal in der Woche anwerfen, replicate, ausschalten. Ruhig schlafen. Ich verlier also maximal die Daten einer Woche beim Datengrab. :bigok:
 
Zuletzt bearbeitet:
Wenn ich bei ZOL einen Pool importiere, dann wird der Mount standdardmässig unter "/" abgelegt.
Weiss jemand, wie man das das generell umbiegen lassen kann, z.B. auf "/mnt" ?
 
Vielen Dank.

-> zfs set mountpoint=/mnt/poolname poolname

macht eigentlich das, was ich wollte.

Was nur auffällt, standardmässig wird nach dem exportieren des Pools das entsprechende verzeichnis unter "/" wieder gelöscht, nachdem ich den Mountpoint nach "/mnt" verändert habe, bleibt das Verzeichnis dort aber nach dem Export bestehen!? Soll das so sein?
 
Hallo, habe hier ein Dataset erzeugt "public". An ACL wurde nix verändert, sprich root=full und everyone=mod. Wenn ich nun einen Ordner "documents" erstelle kann ich aber die ACLs über Windows einfach ändern wie ich lustig bin. Angemeldet unter "user1". Das dürfte doch theoretisch nicht sein oder?

"Change Permissions" zeigt er mir unter Windows keinen Haken für Everyone. Wieso kann ich da dennoch alles ändern?

Verwendet wird omnios und nappit dev
 
Zuletzt bearbeitet:
Hallo, habe hier ein Dataset erzeugt "public". An ACL wurde nix verändert, sprich root=full und everyone=mod. Wenn ich nun einen Ordner "documents" erstelle kann ich aber die ACLs über Windows einfach ändern wie ich lustig bin. Angemeldet unter "user1". Das dürfte doch theoretisch nicht sein oder?

"Change Permissions" zeigt er mir unter Windows keinen Haken für Everyone. Wieso kann ich da dennoch alles ändern?

Verwendet wird omnios und nappit dev

Man müsste sich jetzt die Rechte in documents und public genauer anschauen.
Ich vermute dass das dies hier über owner läuft.

Wer einen Ordner anlegt ist Eigentümer und hat Vollzugriff (Hängt von den übergeordneten ACL und aclinherit ab)
 
Das Dataset vererbt alle Berechtigungen auf erstellte Ordner. Es gibt überall nur root=full und Everyone=modify. "documents" wurde erstellt von user1 und hat dann die Rechte vom Dataset geerbt für root und everyone. user2 kann ebenso die Berechtigungen bearbeiten und ändern
 
Zuletzt bearbeitet:
Da mir ein OmniOS Bug dazu nicht bekannt ist:

- Grundannahme: guest access ist immer disabled, aclinherit=passthrough

- als user anmelden, der den Ordner nicht erstellt hat und damit nicht owner ist, z.B. user 2
kann der auch Rechte ändern?

- Screenshots von Windows (Eigenschaft-Sicherheit) das die ACL von documents aus Windowssicht zeigt
- Screenshot von OmniOS das die ACL von documents aus Unixsicht zeigt:
chmod Ausgabe oder napp-it Ausgabe der ACL (ZFS Filesysten -> ACL on Folders -> documents anwählen)
 
Ich habe es zur Sicherheit selber probiert und konnte den Fehler so nicht nachvollziehen.
Wenn ich von zwei Computern auf das Share zugreife und mich einmal als user 1
und am anderen Computer als user 2 anmelde und jeweils eine Datei erstelle,
konnte ich die Rechte einer Datei die ich nicht selber erstellt habe, nicht ändern.

Bei Dateien des jeweiligen Benutzers konnte ich Rechte ändern. Das liegt an den
besonderen Rechten des Eigentümers. Auch root kann genauso immer ACL ändern,
auch wenn er ebenfalls nicht explizit bei den ACL aufgeführt sein muss. Das Verhalten
dass der Erzeuger einer Datei ACL ändern darf, kann mit aclinherit=restricted beschränkt werden.

Wurde denn an beiden Rechnern nach einem Benutzer gefragt?
Ich bin da auch schon darüber gestolpert, dass ich ohne Eingabe eines Namens/PW
zugreifen konnte, entweder weil ich seit dem letzen Start bereits z.B. als root angemeldet
war oder aber der lokale Benutzer/PW mit einem OmniOS Benutzer übereinstimmt.
 
Mit einer Datei habe ich es noch net probiert muss ich mal machen. Ging in meinem Beispiel um Ordner. Ja beide Computer sind jeweils über einen eigenen Benutzer eingelogt "user1" und "user2"

Aber wenn ich einen Order/Datei erstelle ist es normal dass ich als Ersteller den root ACL Eintrag löschen kann?
 
Zuletzt bearbeitet:
Mit einer Datei habe ich es noch net probiert muss ich mal machen. Ging in meinem Beispiel um Ordner. Ja beide Computer sind jeweils über einen eigenen Benutzer eingelogt "user1" und "user2"

Aber wenn ich einen Order/Datei erstelle ist es normal dass ich als Ersteller den root ACL Eintrag löschen kann?

Natürlich geht das wenn Owner Vollzugriff hat.
Ist aber bedeutungslos da root eh alles darf. Man kann root nicht aussperren.
Man setzt die root allow Regel aber trotzdem gerne damit man alle anderen Rechte einfach entfernen kann und nur root drin läßt.

Man hat so eine klare ACL Regel bei der niemand ausser root was darf.
 
Zuletzt bearbeitet:
Wenn ich in Nappit SSH aktiviere ist ja standardmßig alles "offen". Sprich ich hab ja Zugriff über jeden Benutzeraccount auf alles, selbst auf die ganzen System Dateien. Find ich irgendwie unschön. Kann man das irgendwie deaktivieren?

root kann man ja an und ausschalten, wobei ich da den Sinn nicht so recht verstehe, sprich root kann ich einstellen alle anderen haben aber eh Vollzugriff standardmäßig.

Jeder der nen SMB Passwort hat kann sich ja über WinSCP einklinken und stumpf alles löschen.
 
Zuletzt bearbeitet:
Mal ne Frage für mich als Neuling in ZFS. Gibt es unter Freenas eigentlich eine Möglichkeit, das Filesystem zu benchen? Per LAN bin ich nur auf Gigabit begrenzt und das ist voll ausgelastet.
 
Wenn ich in Nappit SSH aktiviere ist ja standardmßig alles "offen". Sprich ich hab ja Zugriff über jeden Benutzeraccount auf alles, selbst auf die ganzen System Dateien. Find ich irgendwie unschön. Kann man das irgendwie deaktivieren?

Das ist jetzt eine allgemeine SSH Frage und hat mit napp-it direkt nichts zu tun.
Aber prinzipiell arbeitet SSH so. Ein Unix User den napp-it anlegt hat zwar keine Shell kann damit keine Remote Console über Putty öffnen, hat jedoch einen SSH Dateizugriff auf /.

root kann man ja an und ausschalten, wobei ich da den Sinn nicht so recht verstehe, sprich root kann ich einstellen alle anderen haben aber eh Vollzugriff standardmäßig.

Root ist bei Unix standardmäßig als SSH User deaktiviert damit man remote keinen Vollzugriff haben kann.
Man kann ihn aber per napp-it Menü Services-SSH aktivieren um Remote administrieren zu können.
Andere User haben aber keinen Vollzugriff sondern nur die Rechte des jeweiligen Users

Jeder der nen SMB Passwort hat kann sich ja über WinSCP einklinken und stumpf alles löschen.

Relevant ist nicht das SMB Passwort sondern das Unix Passwort.
Aber natürlich kann ein User nur die Dateien löschen/ ändern auf die er Zugriff hat.

Bleibt die Frage wie man mit SSH umgehen sollte (eigentlich mit allen Serverdiensten)

- SSH deaktivieren wenn man es nicht braucht (die wichtigste Regel)
- starke Passworte nutzen
- per Firewall den Zugriff auf einzelne Clients beschränken
- keine lokalen User anlegen sondern Verzeichnisdienste z.B. Active Directory nutzen

- - - Updated - - -

Mal ne Frage für mich als Neuling in ZFS. Gibt es unter Freenas eigentlich eine Möglichkeit, das Filesystem zu benchen? Per LAN bin ich nur auf Gigabit begrenzt und das ist voll ausgelastet.

Üblicherweise nimmt man tools wie bonnie oder macht einen Schnelltest mit dd, egal welches Unix.
z.B. http://www.thomas-krenn.com/de/wiki/Linux_I/O_Performance_Tests_mit_dd
 
Zuletzt bearbeitet:
Relevant ist nicht das SMB Passwort sondern das Unix Passwort.
Aber natürlich kann ein User nur die Dateien löschen/ ändern auf die er Zugriff hat.

Bleibt die Frage wie man mit SSH umgehen sollte (eigentlich mit allen Serverdiensten)

- SSH deaktivieren wenn man es nicht braucht (die wichtigste Regel)
- starke Passworte nutzen
- per Firewall den Zugriff auf einzelne Clients beschränken
- keine lokalen User anlegen sondern Verzeichnisdienste z.B. Active Directory nutzen

Naja alles leider keine so richtigen Lösungen für mich: AD hat man halt privat nicht. Starke Passworte benutze ich sowieso. Deaktivieren ist auch net so toll denn falls das Webinterface mal streiken sollte hab ich dann nur noch die Möglichkeit Lokal das ganze wieder zu reparieren. Und wenn ich SSH deaktiviere, hab ich ja auch kein SFTP mehr. Hier ist die Frage ob ich SFTP um sicher Dateien zu übertragen, also übers Internet, überhaupt noch benutzen sollte, oder besser gleich WebDAV dafür nehmen?

Relevant ist nicht das SMB Passwort sondern das Unix Passwort.
Aber natürlich kann ein User nur die Dateien löschen/ ändern auf die er Zugriff hat.
Ja schon klar aber für jedes SMB Passwort wird ja auch nen Unix Passwort erstellt. Hätte es gern so dass nur root sich über SSH einloggen kann und alle anderen nicht. Kann man alle anderen user nicht einfach sperren?
 
Zuletzt bearbeitet:
Ja schon klar aber für jedes SMB Passwort wird ja auch nen Unix Passwort erstellt. Hätte es gern so dass nur root sich über SSH einloggen kann und alle anderen nicht. Kann man alle anderen user nicht einfach sperren?

Man kann alle anderen User manuell sperren durch einen Eintrag in der /etc/ssh/sshd_config
Den kann man per napp-it Menü Services - SSH - server settings vornehmen

DenyUsers peter,paul

edit
es reicht ein (um alle anderen zu sperren, habs gerade getestet)
AllowUsers root

Anschliessend SSH neu starten
Ich finde das sogar ganz sinnvoll, werde das als Option in napp-it einbauen
 
Zuletzt bearbeitet:
cool:)
thx
Nur Schade dass SFTP mit SSH zusammenhängt. Aber macht SFTP noch Sinn heute? Hab ein Dataset per FTP freigegeben würde aber gern etwas mehr Sicherheit reinbringen.Als Alternative kommt SFTP oder WebDAV in Frage. WebDAV scheint aber moderner zu sein oder gibt es irgendwas was für SFTP heute noch sprechen würde zum Datenaustausch übers Internet?
 
Du solltest dir vorher klar werden,
- welchen Raid-z-Level du haben willst,
- dann wieviel vdevs pro pool,
- ob du den Pool mit ashift=9 oder ashift=12 anlegen willst,
- dann erst kannst du die Anzahl der HDDs pro vDev festlegen,
um so wenig wie möglich Verluste zu haben.

Deine Anmerkungen klingen vernünftig, ja es handelt sich vorwiegend um Multimedia-Daten, daher wird dann wohl Raid-Z2 reichen.
Ich habe mir nur einen Pool vorgestellt, das wären dann maximal 4 VDEVs mit je 6 Platten.

Wenn ich das hier richtig interpretiere, dann heißt das:
Ashift=9: weniger Schreib-Performance bei 4k HDDs, aber mehr Netto-Speicherkapazität
Ashift=12: mehr Schreib-Performance bei 4k HDDs, aber merklich weniger Netto-Speicherkapazität

Bei den Festplatten bin ich noch etwas am Überlegen, ich hätte ja rein aus dem Bauch heraus schon zu den WD Red tendiert, allerdings frage ich mich langsam ob das bisschen Stromersparnis wirklich sinnvoll ist und ich nicht doch lieber die HGST Desktstar NAS Variante vorziehen soll (bessere Performance => weniger Zeit beim ev. Resilvern etc.)
Schlafen legen kann ich ja beide Modelle oder?
Bezüglich der Vibrationsthematik habe ich bis dato noch nichts gehört, aber werde das beherzigen und dann doch wohl auf die 4TB Modelle zurückgreifen.

Was versteht man konkret unter einer "kleinen USV" im semi-professionellen-/Homebereich?

Das mit dem Backupserver ist eine ausgezeichnete Idee, das werde ich dann so mitnehmen und den alten für Backupzwecke missbrauchen, steht ja eh sonst nur rum und verstaubt.
 
Wenn ich das hier richtig interpretiere, dann heißt das:
Ashift=9: weniger Schreib-Performance bei 4k HDDs, aber mehr Netto-Speicherkapazität
Ashift=12: mehr Schreib-Performance bei 4k HDDs, aber merklich weniger Netto-Speicherkapazität

Ich würd mich auf das Spielchen nicht einlassen, denn auch wenn du eine Erweiterung des Arrays per Plattentausch ausschließt, bist du nicht vor Defekten sicher. Bitte korrigiert mich wenn ich da falsch liege, aber ZFS wird ein Laufwerk mit ehrlich gemeldeten 4K-Sektoren ums Verrecken nicht in ein Array mit ashift 9 eintauschen. Daher verbaust du dir mit ashift 9 nicht nur langfristig den Upgradeweg durchs serielle Tauschen aller Platten, sondern schränkst bei künftigem Tausch wegen Defekt auch deine Auswahlmöglichkeiten an Ersatzplatten ein. Mir wärs das nicht wert, grade wenn vorwiegend "Multimedia-Daten" draufliegen, die ohnehin viele MB bis GB groß sind, wo ein vergeudeter letzter Sektor pro Disk nicht wirklich viel ausmacht.

Was versteht man konkret unter einer "kleinen USV" im semi-professionellen-/Homebereich?
Kann da nur für mich und mein bescheidenes Setup sprechen - bei mir ist ne APC Back-UPS ES 700VA (405W) im Einsatz, wahrscheinlich gut überdimensioniert, aber praktisch gleichteuer wie kleinere APCs. Hab ich damals für 65€ neu inkl. Versand bekommen, da kann ich überhaupt nicht meckern...
 
Ich habe mir nur einen Pool vorgestellt, das wären dann maximal 4 VDEVs mit je 6 Platten.
Wenn du dich jetzt entschieden hast einen RaidZ2 und 4k Pool aufzubauen, dann such mal hier im Thread nach, welche Anzahl an HDDs bei 4k zu nehmen sind, um möglichst keinen Overhead zu haben. (Wurde von mir hier diskutiert Anfang 2014) oder such im Hardforum oder Patricks STH Forum.
https://forums.servethehome.com/index.php?threads/4k-green-5200-7200-questions.30/ , [H]ard|Forum - View Single Post - RAIDZ2 space efficiency problem
(Sorry, bin aber gerade auf dem Sprung fort zu gehen)

Ich würde bei einem so großen Pool, in jedem Falle eine Spare-HDD einbauen, damit wenn ZFS feststellt, dass eine HDD zu viele Fehler aufweist, Diese aus dem Pool wirft, die Spare aktiviert und den Pool wieder in Ordnung bringt.

Mein Hinweis auf ashift=9 oder 12 bezog sich nicht auf die unterschiedliche Speicherkapazität, sondern wie @Bzzz dir schon geschrieben hat, auf die Zukunftssicherheit beim HDD-Tausch.
4K Sectors and ZFS » George Wilson

Was die USV betrifft ging es mir darum, dass wenn Spannungsspitzen oder kurzer Stromausfall im Stromnetz vorkommen, dein Server davor geschützt ist. Wir haben ja Gott sei Dank nicht amerikanische Verhältnisse, aber allein dieses Jahr hatten wir hier schon drei Mal Stromausfälle im Bereich von < 1 Sekunde Dauer, aber es reicht, dass die Rechner down sind.
Ich hatte keine USV gemeint, welche den Server mehrere Stunden am Laufen hält, ist für deinen Bedarf vollkommen unnötig und das Geld zum Fenster raus geworfen.
 
Zuletzt bearbeitet:
Bezüglich des Overheads bzw. Optimale Anzahl an Platten bei 4K HDDs ist dieser Artikel ganz gut:

http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/

Wenn man Kompression einsetzt ist mMm die (2^number of Disks)+parity Formel nicht mehr 100% richtig - auch wenn es Multimediadatein sind die nur ein wenig Komprimiert werden können.

Was ist aus dem Verlinkten Artikel verstanden habe ist, dass der overhead bei raidz1-3 weniger wird je mehr Platten enhalten sind und das der Overhead bei grossen Dateien (zB Multimedia) die die default recordsize von 128k nutzen eh zuvernachlässigen ist.
 
Zuletzt bearbeitet:
Der Artikel ist durchaus interessant, aber:
Ein Stripe wird doch über alle Platten gleichmässig angelegt! (Oder wozu dient die Stripegrösse?)
Die Stripegrössen sind ganzahlige Potenzen zur Basis 2 (ich vermute mal, daß die Stripegrösse die Nettokapazität des Stripes beschreibt, da diese über alle Raidz Level gleich sind.

Ich nehme jetzt als Basis die standard Stripegrösse von 128K.
jetzt "analysiere" ich ein Raidz1 aus 6 Platten (5+1)
128 K /5 = 25,6 K >>> =26214,4 Byte
26214,4/512Byte/Sektor = 51,2 Sektoren
Daraus folgt daß ich Pro Platte 52 Sektoren verwenden muss, um die Stripegrösse anlegen zu können, macht Pro Stripe einen Verlust von 5x0,8 = 4 Sektoren aus >> 2KByte Verlust Pro Stripe

Das ganze nun mit 4K Platten
26214,4 Byte / 4096Byte/Sektor = 6,4 Sektoren
Daraus folgt daß ich Pro Platte 7 Sektoren verwenden muss, um die Stripegrösse zu anlegen zu können, macht Pro Stripe einen Verlust von 5x0,6 = 3 Sektoren aus >> 12KByte Verlust Pro Stripe
Dieser Verlust ist Speicherplatz der schlichtweg verloren geht, da er nirgendwo mehr verwaltet wird kann.

Der Artikel geht auf diese Tatsache gar nicht ein. Das ist aber letztendlich die Grundlage für die optimale Kapazitätsausnutzung.
Hinzu kommt noch der kleine Verlust am "Ende", da die Gesamtzahl der Sektoren einer Festplatte i.d.R. ebenfalls einer 2er Potenz entspricht, und diese sich meist auch nicht durch z.B. 7 Teilen lässt, es bleiben also einige Sektoren als Rest übrig, das kann allerdings auch passieren, wenn man z.B. 16 Datenplatten hat und die Gesamtzahl der Sektoren nicht durch 8 teilbar ist (128K Stripegrösse / 16 Platten).

Der Verlinkte Artikel macht nur dann Sinn, wenn die Stripegrösse bei der Initialisierung des Dateisystems zwar angewendet wird, aber schlussendlich beim Speichern von Daten überhaupt nicht relevant wäre und ZFS mit kleineren Speicherblöcken arbeitet : "RAID-Z parity information is associated with each block, rather than with specific stripes as with RAID-4/5/6......"
Dieser Absatz suggeriert dieses....
Vor allem ist hier von Blöcken die Rede, was ist ein Block, wie gross ist der, wo wird die Grösse definiert etc.
 
Zuletzt bearbeitet:
Ich gebe zu, ich habe den Thread nicht weiter verfolgt - da aber ZFS immer wieder als DAS Allheilmittel gegen alle Storage Probleme angepriesen wird:

Kann ich einen bestehenden ZFS Pool mittlerweile auch um mehr Platten erweitern? Oder bleibt weiterhin die Einschränkung größere Platten ja, mehr Platten nein?
 
Einzelne vdevs lassen sich nur so erweitern. Du kannst natürlich einen Pool aus mehreren vdevs erstellen und so die Erweiterung durch mehr Platten durchführen. Fällt dir allerdings eine vdev des Pools aus, ist der gesamte Pool weg. Also die Antwort lautet ja, und da das in der Architektur begründet liegt wird sich das vermutlich auch ich ändern.
 
...

Der Verlinkte Artikel macht nur dann Sinn, wenn die Stripegrösse bei der Initialisierung des Dateisystems zwar angewendet wird, aber schlussendlich beim Speichern von Daten überhaupt nicht relevant wäre und ZFS mit kleineren Speicherblöcken arbeitet : "RAID-Z parity information is associated with each block, rather than with specific stripes as with RAID-4/5/6......"
Dieser Absatz suggeriert dieses....
Vor allem ist hier von Blöcken die Rede, was ist ein Block, wie gross ist der, wo wird die Grösse definiert etc.

Ist eigentlich alles sehr schön erklärt in dem Artikel und du hast ja auch richtig gerechnet, der Verlust durch 4K Sektoren kann tatsächlich erheblich sein.
Aber:
ZFS verwendet variable Stripes, (Standard max. 128k, aktueller Code geht bis 1MB).
Ein Block wird definiert durch Sektorgröße mal Plattenanzahl (in deinem Beispiel also 512 Byte bzw 4096 Byte mal 6 Platten), das gilt allen Varianten von RAID-Zx.
Also Sektor -> Block -> Stripe
Daraus folgt logischerweise das die kleinste mögliche Stripesize immer der Blocksize entspricht.

Alles klar?

cu
 
Das heist die Stripesize ist nicht zwingend eine Potenz zur Basis 2 sondern abhängig von der Anzahl der verbauten Platten?
Zum Beispiel wie bei mir zur Zeit:
ein Raidz2 aus 7 Platten mit 4K Sektoren (NAS4Free: Enable Advanced Format (4KB sector) ) würde eine minimale Stripesize von 5x4K = 20K (Netto) und entsprechende vielfache davon ergeben?
Demnach habe ich einen "Fehler" gemacht als ich den Standardwert von 128K übernommen habe ( recordsize = 128K) >> z.B 120K oder 140K wäre besser gewesen (in der Annahme, daß sich die Strippesize auf die Nettokapazität bezieht) ?

Das wäre dan also unter der Rubrik "wieder was dazugelernt" zu betrachten, und findet beim nächsten NAS Berücksichtigung. Muss "NUR" noch rausfinden wo ich das beim Erstellen unter NAS4Free einstellen kann :-) (Dauert ja nur noch bis Januar/Februar).
Evtl wechsle ich auch zu FreeNAS, da ich den Eindruck habe, daß bei FreeNAS die Weiterentwicklung mit mehr Elan vorangetrieben wird. Oder aber der Umkehrschluss ist das NAS4Free derzeit stabiler ist :)
Im Übrigen wäre das ein weitereres Argument, warum ZFS flexibler als ein Hardware-Raid ist.
 
Zuletzt bearbeitet:
Weiß jemand von aktuellen Benchmarkergebnissen des letzten Releases?

Ich habe ein Mobo Software Raid 0 aus 3x 3TB Barracuda ext4 und wüsste gerne ob mir ZFS bessere Lese bzw. Schreibgeschwindigkeiten liefern könnte.

Ich konnte nur diese vermutlich veralteten Performance Vergleiche finden: [Phoronix] Benchmarks Of The New ZFS On Linux: EXT4 Wins

Zusätzlich wäre ich auch an cachen mit einer SSD bzw. RAM (da 16GB 2400 vorhanden) interessiert.
Würde ZFS hierbei mehr bzw. performantere Features bieten?

Hier gehts wirklich nur um Performance, wobei kein Bedarf an redundancy vorliegt.:)
 
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