Raidzx (1,2,3) - Stripesize einstellen

[Digi-Quick]

Moin,
kann ich bei N4F beim Anlegen eines RaidzX (1,2,3) keine andere Stripesize als 128K (Default) einstellen? (z.B. 256K)

Ich habe schon durch alle Einstellungsdialoge durchgeschaut und kann nichts entsprechendes entdecken.
Die Frage bezieht sich auf die aktuelle Version.
Bei 24 Disks als Raidz3 mit 4K/AF Platten ist 128K äusserst ungünstig

ciao
Lothar

[Princo]

Beantwortet das nicht deine Frage?: http://forums.freebsd.org/threads/4k-bl ... ost-212716

Grüße
Princo

[Digi-Quick]

eher weniger!
Laut diesem Artikel ist es "egal" wie viele Disks ein RaidzX bilden.
http://blog.delphix.com/matt/2014/06/06 ... ipe-width/

Für mich stellt sich einfach die Frage, habe ich Platzverlust bei einem Raidz3 aus 24 (21+3) Platten wegen der nicht angepassten "physikalischen Stripesize", die sich aus der Anzahl Platten ergibt. 128K /4K Sektorgrösse /21 Platten = 1,5 Sektoren / Platte.
Daraus würde folgen, daß ein 128er Stripe 2 Sektoren / Pro Platte belegt und 1/2 Sektor Verlust pro Platte und Stripe entsteht.

Folglich müsste die Stripegrösse 1 Sektor/Plattte x 4 K Sektor x 21 Platten = 84 K sein (bzw. ein vielfaches davon) um eine optimale Ausnutzung zu haben.

Bei einem Raidz3 aus 19 Platten (16+3) würde der Stripe genau aufgehen
128K / 4K Sektorgrösse /16 Platten = 2 Sektoren / Platte

Die essentielle Frage ist also ob es klug ist bei 24 Platten 1 Raidz3 über alle Platten zu erstellen (21+3) oder ein Raidz3 aus 19 Platten (16+3) und die verbleibenden 5 Platten als Raidz1 zu nutzen (2 eigenständige Pools).
Es geht hierbei nicht um die Performance , nur um eine möglicherweise unnötige Platzverschwendung.

Da eigentlich die gesamte IT auf dem Binärem Zahlensystem basiert und mit Potenzen zur Basis 2 rechnet, erscheint es mir eigentlich unwirklich, daß jetzt ausgerechnte ZFS hiervon nicht betroffen sein soll

[crowi]

Ich würde mich da eher an die best practices von Oracle halten:
RAIDZ Configuration Requirements and Recommendations
A RAIDZ configuration with N disks of size X with P parity disks can hold approximately (N-P)*X bytes and can withstand P device(s) failing before data integrity is compromised.
Start a single-parity RAIDZ (raidz) configuration at 3 disks (2+1)
Start a double-parity RAIDZ (raidz2) configuration at 6 disks (4+2)
Start a triple-parity RAIDZ (raidz3) configuration at 9 disks (6+3)
(N+P) with P = 1 (raidz), 2 (raidz2), or 3 (raidz3) and N equals 2, 4, or 6
The recommended number of disks per group is between 3 and 9. If you have more disks, use multiple groups.
Ein einzelnes vdev mit 21 oder 24 Platten ist sehr gewagt...

[Princo]

Hi Digi-Quick,

Vorab erst mal etwas Lesestoff:
https://wiki.archlinux.org/index.php/ZFS#Database
https://wiki.archlinux.org/index.php/ZF ... ical_disks
http://www.zdnet.com/blog/storage/why-r ... n-2009/162

Du kannst bei ZFS-Pools eine Recordsize von 512 to 128k, power of 2 einstellen. Dies kann für den ganzen Pool, oder auch für einzelne Datasets getrennt definiert werden. Höhere Werte sind nicht möglich (das bezieht sich auf ZFS Pool Version 28).

Das kann man nicht über das Web-GUI einstellen, weil NAS4Free da doch eher für den Heimanwender konzipiert ist, aber über die Kommandozeile ist das möglich.

Ob das allerdings tatsächlich etwas bringt, hängt natürlich von deinen Daten ab, und wie du darauf zugreifst.
Neben der Möglichkeit an der "recordsize" herumzuschrauben, gibt nämlich auch noch die Option mit der "compression" zu arbeiten. Das kann aber auch alle vorherigen Ergebnisse/Annahmen auf den Kopf stellen.

Zu deiner Frage

Die essentielle Frage ist also ob es klug ist bei 24 Platten 1 Raidz3 über alle Platten zu erstellen (21+3) oder ein Raidz3 aus 19 Platten (16+3) und die verbleibenden 5 Platten als Raidz1 zu nutzen (2 eigenständige Pools). Es geht hierbei nicht um die Performance , nur um eine möglicherweise unnötige Platzverschwendung.

Wow, 24 Platten! Von welcher Hardwareumgebung reden wir hier eigentlich?

Ansonsten möchte ich noch etwas zum Statement von crowi hinzufügen, und da kommt der oben aufgeführte dritte Link besonders ins Spiel: diese "best practices von Oracle" basieren auf Festplattengrößen von weit unter 1TB. In deinem Anwendungsbeispiel solltest du eigentlich nichts mehr mit RaidZ1 machen.
Wie sieh das eigentlich mit einem Backup aus?

Grüße
Princo

[Digi-Quick]

Wir reden über 24x5TB!
Nach derzeitiger Preisrecherche und Abwägung von Sromverbrauch und Herstellergarantie werden es wohl die Seagate Archive Platten mit 5 TB / 5900 U/min / 5 watt Idle / 2 Jahre Hertsellergarantie für ca. 160 €/Stück, das kann sich aber je nach Preisentwicklung / Produktneuheiten bis Januar noch ändern!

Das System ist für ein Media-Datenarchiv, welches grösstenteils nicht gesichert wird. Wenn die Daten tatsächlich weg sind, brauche ich zwar ein Beissholz, aber es wäre zu verschmerzen, da die Daten wären letztendlich wiederzubeschaffen sind, was dann hauptsächlich Zeit kostet.

Für die wichtigen Daten steht noch ein HP-N54L mit zur Zeit 5x4 TB im Raidz1 zur Verfügung, dieser soll als Backup genutzt werden (wahrascheinlich eher umgekehrt, da der HP wohl den geringeren Stromverbrauch hat).

Möglichkeit 1: 24x5 TB als Raidz3, die per HP-N54L gesicherten Daten liegen dann hier mit drauf.

Vorteil: die gesicherten Daten eigen auf einem Raidz3 und einem Raidz1, die Verlustwahrscheinlichkeit dieser Daten wäre also statistisch gesehen noch geringer als bei Möglichkeit 2.
Nachteil: 1. Die zu sichernden Daten müssten logisch über die Verzeichnisstruktur separiert werden - würde ich nicht unbedingt als krassen Nachteil sehen.
2. Möglicherweise der angesprochene Platzverlust, wobei dieser möglicherweise durch die Kompression etwas aufgefangen wird.


Möglichkeit 2: 19x5 TB als Raidz3 für's Archiv - ohne weiteres Backup & 5x5TB als Raidz1 für die via HP-N54L zu sichernden Daten.

Vorteil: 1. Reines Datenarchiv und gesichertes Datenarchiv wären physikalisch und logisch getrennt.
2. Kein möglicher Platzverlust durch "krumme" Anzahl an Platten 2^n Datenplatten + x Parityplatten wäre eingehalten.
Nachteil: 1. Statistisch höhere Verlustwahrscheinlichkeit
2. 1 Parityplatte mehr (4 satt 3), dadurch in Summe rechnerisch weniger Kapazität - und Real??

Zum Thema Kompression: Ich geha davon aus, daß sich die Daten eher schlecht komprimieren lassen - hauptsächlich sind es grosse Mediadaten (ca. 2MB bis 30GB).
Das System wird nicht 24/7 laufen, sondern nur bei Bedarf (24 Platten ziehen ja auch ein wenig Strom) - also eher 3-5h am Tag.
Das Gehäuse habe ich schon hier, das Silence Rack kommt die nächsten Tage. Die Hardware wird in den nächsten 2 Wochen gekauft, die Platten dann im Januar.

[Princo]

Hi Digi-Quick,

Das klingt spannend, und anscheinend weißt du auch, was du da tust (das hoffe ich zumindest)
Ich mag es ja, mit großen Datenmengen zu hantieren, aber der 100TB-Bereich ist eine ganz neue Herausforderung.

Ein System mit 24 Festplatten ist nicht so einfach zu handhaben, und wenn ich dein Einsatzszenario richtig interpretiere, dann ist das ein Medienarchiv, bei dem du dir ca. 3 Filme/Tag anschaust, oder ein paar Stunden Musik hörst.

Es ist also kein System, auf das tausende Leute gleichzeitig 24/7 Zugriff haben sollen.

Daher würde ich eher zu einer anderen Lösung tendieren, weil ein solch riesiges Array in diesem Fall mehr Nach- als Vorteile bringt.

Mein Vorschlag wären mehrere Pools aus 4x5TB RaidZ1 Elementen, welche getrennt voneinander eingeschaltet werden können. Dazu müßte man zwar vorher wissen, in welchem Pool die benötigten Daten liegen, aber es hätte den Vorteil, daß nur die Platten in Betrieb sind, welche man tatsächlich braucht (Betriebsstunden!).

Außerdem mußt man nicht auf einen Schlag ein riesiges Array bauen, sondern könnte das System nach dem jeweils tatsächlichen Bedarf erweitern, und dabei Vorteile aus fallenden Preisen und ggfs. noch höheren Speicherkapazitäten mitnehmen.

Dazu würde sich ein System aus kleineren Speichergruppen sehr viel einfacher handhaben lassen, auch wenn ZFS für große Lösungen bestens geeignet ist (4x5TB sind aber auch schon ziemlich groß).

24 Festplatten erzeugen auch Einiges an Abwärme, Vibrationen und Geräusch, und wie das mit den Anlaufströmen ist, steht nochmal auf einem gesonderten Blatt.

Überleg mal, ob diese Konfiguration mit den kleinen, flexiblen Einheiten nicht evtl. besser für dein Projekt geeignet ist. Den Verlust duch die Sektorgrößen habe ich dabei vorerst nicht weiter berücksichtigt.

Grüße
Princo

[b0ssman]

die theorie sagt zumindest das ein 24 platten raidz3 ziemlich sicher ist.

http://www.servethehome.com/raid-calcul ... tdl-model/

[Digi-Quick]

@Princo,
Sicherlich ein gut gemeinter Tip, aber ich will weg vom Nachschauen müssen auf welcher Festplatte bzw. dann auf welchem Pool sich jetzt eine bestimmte Datei befindet.
Auch eine logische Trennung klappt bis zu einem Bestimmten Punkt und dann nicht mehr, und dann ist man wieder am Neustrukturieren und reorganisieren, was meist mit Datentransfers von mehreren TeraByte verbunden ist.

Das NAS ist so gross geplant, daß es für die nächsten 5 Jahre reichen sollte.
Meine Frau hat noch ca. 250 Hi8 / D8 Camcordercasetten, die digitalisiert / überspielt werden sollen, dann will Sie zigtausend Dias, Fotos und Dokumente einscannen usw....


In 5 Jahren wird dann wohl das nächstgrössere NAS gebaut

Richtig erkannt: kein 24/7 Multiuserbetrieb, das zeitgleich 2 Clients zugreifen ist eher die Ausnahme. von daher ist die performance nachrangig, da bin ich schon mit meinem jetzigem NAS zufrieden.
Besteht im übrigen aus 7x3TB im Raidz2 und 7x 1,5TB im Raidz2 auf 2 Pools und steckt in einem einfachem LianLi A70 Gehäuse (mit den 6 mitgelieferten 120er Gehäuselüftern, die auf 5V laufen) - Leise ist anders .
Das neu System kommt in ein http://www.xcase.co.uk/rackmount-cases/ ... -case.html in einem Silencerack (http://www.it-budget.de/schallgedaemmte ... f4ece7588a) beides schon da, der Rest der Hardware wird in den kommenden 6-8 Wochen angeschafft.

[Princo]

@Digi-Quick

Das setzt neue Maßstäbe. Respekt.
Mit welchem System wirst du das eigentlich ansteuern, und welchen RAM-Ausbau hast du dafür eingeplant?

Etwas OT: Da du das Einscannen von Fotos und Dias erwähnt hast: Das steht bei mir auch an, und ich schiebe es schon seit ein paar Jahren vor mich her.
Werdet ihr dafür eine Software einsetzen, um die Bilder zu organisieren, oder werdet ihr das rein über die Dateisystemstruktur realisieren?
Mein Problem ist nämlich, daß sich "meine" Bilder völlig durcheinander gewürfelt in mehreren Kartons befinden, und ich schon große Schwierigkeiten damit habe, diese in eine grobe zeitliche Reihenfolge zu bringen.
Anmerkung: Diesen Bildbestand habe ich von meinen Eltern geerbt.
Meine Suche nach einer entsprechenden Softwareunterstützung war bisher leider erfolglos.
Für Fotos aus Digicams gibt es zwar haufenweise Software, aber für digitalisierte Analog-Fotos ist die nicht richtig brauchbar.
Daher werde ich für einen Tipp diesbezüglich dankbar.

Grüße
Princo

[Digi-Quick]

Supermicro X10SL7-F (wird auf IT Mode geflasht)
zusätzlich 2 LSI 9211 8i (werden ebenfalls auf IT Mode geflasht, ohne BIOS)
vorher wird überall stagerred Pinup aktiviert.
Bei der CPU bin ich mit mir noch nicht einig (Vernuft vs. Gier).
Auf Grund der bisherigen Erfahrungen mit meinen jetzigen NASen (Selbstbau und HP Microserver) sollte eigentlich ein G1820 reichen.... (mein E8400 ist langsamer).
Besser, Schöner, Weiter und Überhaupt.... wäre der Xeon E3-1220 v3. Irgendwo dazwischen liegen dann noch der Pentium G3220 und der Core i3-4150. Vorteile eines schnelleren Prozessors sehe ich bei meinem Anwendungsfall eigentlich nur beim Scrubben oder Resilvern.

Arbeitsspeicher wird erstmal 16 GB ECC (2x8) eingesetzt - Option auf 32 GByte (mehr kann das Board eh nicht).
Mein derzeitiges Selbstbau NAS läuft mit 4 GB auch brauchbar, zu den 16 GB im HP Microserver merke ich jetzt nicht den riesen Unterschied. Caching Algorithmen sind nunmal erst bei wiederholtem Zugriff wirklich wirkungsvoll. Das einzige was Wirkung bringt, ist der Read-Ahead-Cache.

Als OS werde ich mir wohl nochmal die aktuelle Version von FreeNAS anschauen und OmniOS in Verbindung mit NappIT zu Gemüte führen, wobei letzteres "näher" an der klassischen Konsole ist - ich habe ja Zeit, Die Platten brauchen ja auch einige Tage bis Sie mit dem Burn-in durch sind (kompletter Oberflächen Scan und Schreib/Leseprüfung mit h2testw)


Zum Thema Fotos: bislang wird alles rein auf Dateisystemebene verwaltet (...\Datum-Ereignis\Aufnahmedatum - lfd-Nr.*)
Bei den einzuscannnenden Fotos haben wier uns noch nichts weiter überlegt. Es wird sich alos zeigen, ob wir da auch mit der bisherigen Methode weiterkommen, oder ob wir da andere Möglichkeiten in Betracht ziehen müssen.
ACDsee ist ja eigentlich ziemlich mächtig, was die Verschlagwortung (was für ein Wort) von Fotos angeht, bislang haben wir diese Fähigkeiten (und die Datenbank) von ACDsee noch nicht genutzt.