Der ultimative Linux (Hardware-) Raid Aligment Filesystem Benchmark Sammelthread

Super Idee und vor allem tolle Threadtitel :D;)

littledevil;450502 said:
Super Idee und vor allem tolle Threadtitel :D;)

Stimmt :d:
Endlich wird das Thema mal vernünftig angegangen \D/

drdope;450557 said:
Update:
Stardate 20110327.0444 […]

Hoffentlich wissen die Leute , das du Nachtschichtler bist -> ansonsten (kranker) Nerd 😯 – aber trotz alledem, um 4:44 Uhr Nachts so ‘ne gute Arbeit zu machen verdient :respekt: (ich hoffe, es musste keiner dafür “leiden” *kicher*)

B2T – Update EXT3:
Der einzige Parameter den man beim Erstellen des Filesystems benutzen muss ist der Schalter “-E” (für “extended Attributes”)
[CODE]mkfs.ext3 -E stride=16 /dev/blah[/CODE]
stride=x gibt an, wieviele FS-Blöcke im Rutsch gelesen/geschrieben werden sollen und muss auf die jeweile Stripe-Size angepasst werden:
Beispiel: 64k Stripe-Size und 4k-Blöcke ergibt “stride=16″ (16*4=64)
Den Rest macht das Filesystem von selber.

Vorteile vom EXT3 sind die Rückwärtskompatibilät zu EXT2, seine Robustheit und die Menge an verfügbaren Tools, z.B. auch für Cross-Plattform:
–> http://ext2read.blogspot.com/ (Can read EXT2/3/4 Partitions from Windows even in LVM … -> BartPE support!)

Nachteile sind vor allem die Einschränkungen der maximalen Dateigröße, und die maximale Dateisystemgröße:
–> http://en.wikipedia.org/wiki/Comparison_of_file_systems

[TABLE]
EXT3 – max. Dateigröße: 16 GiB to 2 TiB[6] – max. FS-Größe: 2 TiB to 32 TiB
XFS – max. Dateigröße: 8 EiB[29] – max. FS-Größe: 16 EiB[29]
EXT4 – max. Dateigröße: 6 GiB to 16 TiB[6] – max. FS-Größe: 1 EiB
BTRFS – max. Dateigröße: 16 EiB – max. FS-Größe: 16 EiB
[/TABLE]

[SIZE=”1”][6] For filesystems that have variable allocation unit (block/cluster) sizes, a range of size are given, indicating the maximum volume sizes for the minimum and the maximum possible allocation unit sizes of the filesystem (e.g. 512 bytes and 128 KiB for FAT — which is the cluster size range allowed by the on-disk data structures, although some Installable File System drivers and operating systems do not support cluster sizes larger than 32 KiB).
[29] XFS has a limitation under Linux 2.4 of 64 TiB file size, but Linux 2.4 only supports a maximum block size of 2 TiB. This limitation is not present under IRIX.
[/SIZE]

–> http://en.wikipedia.org/wiki/Ext3
Wenn man mal die Werte vergleicht, wird schnell klar, das man für grosse RAID-Systeme mit modernen Festplatten schon die Möglichkeiten von EXT3 ausreizt. (16x 2TB sind kein Problem mehr, bei 3TB Festplatten ist EXT3 ‘overbudget’). Daher empfehle ich EXT3 nur bei kleineren RAIDs einzusetzen (hauptsächlich wegen seiner breiten Unterstüzung durch Tools). Für alles andere ist klar XFS zu empfehlen – bis BTRFS mal erwachsen ist.

Man sollte auch beachten, das EXT3 normalerweise 4k-Blöcke nutzt, welche sich mit dem internen Linux-Aufbau in 4k-Pages deckt, man hat hier also keine Fragmentierungsverluste. Wenn man nun andere Blockgrössen einsetzen möchte, schwindet dieser “Vorteil”. Und man bewegt sich schon im Bereich des speziellen Dateisystem-Tunings.

Update XFS:
Das gleiche gilt für XFS:
–> http://en.wikipedia.org/wiki/XFS
Variable block sizes
The file system block size represents the minimum allocation unit. XFS allows file systems to be created with block sizes ranging between 512 bytes and 64 kilobytes, allowing the file system to be tuned for the expected use. When many small files are expected a small block size would typically maximize capacity, but for a system dealing mainly with large files, a larger block size can provide a performance advantage.

–> http://oss.sgi.com/projects/xfs/papers/xfs_filesystem_structure.pdf , Seite 7:
sb_blocksize
The size of a basic unit of space allocation in bytes. Typically, this is 4096 (4KiB) but can range from 512 to 65536 bytes.

Sodele, dann bastel das mal rein 🙂

Sc0rp

PS: Ich hab das mit der Tabelle nicht so gut drauf, irgendwie fehlt mir der Syntax dazu -> kann mir mal jmd. dafür ‘nen Hint bzw. ‘nen Tip geben? Ein (vorhandenes) Beispiel würde auch gehen ;).

PPS: an der Alingment-Sache arbeite ich noch …

Sc0rp;450571 said:
stride=x gibt an, wieviele FS-Blöcke im Rutsch gelesen/geschrieben werden sollen und muss auf die jeweile Stripe-Size angepasst werden:
Beispiel: 64k Stripe-Size und 4k-Blöcke ergibt “stride=16” (16*4=64)
Den Rest macht das Filesystem von selber.

stride bezieht sich auf die chunk-size und nicht auf die stripe-size. (Vorausgesetzt die Begrifflichkeiten bei euren Raid-Controllern sind wie üblich)

Hey Zoldan,

Zoldan;450585 said:
stride bezieht sich auf die chunk-size und nicht auf die stripe-size. (Vorausgesetzt die Begrifflichkeiten bei euren Raid-Controllern sind wie üblich)

Und die Quellenangabe?

Hier meine:
–> http://linux.die.net/man/8/mkfs.ext3

-E extended-options
Set extended options for the filesystem. Extended options are comma separated, and may take an argument using the equals (‘=’) sign. The -E option used to be -R in earlier versions of mke2fs. The -R option is still accepted for backwards compatibility. The following extended options are supported:
stride=stripe-size
Configure the filesystem for a RAID array with stripe-size filesystem blocks per stripe.

>>> Ich sehe da nix mit Chunks … nur was von Stripes!

Abgesehen davon ist auch der Terminus stride=stripe-size inhaltlich falsch, es müsste heissen stride=stripe-size/fs-blocksize.

Und den Unterschied zwischen Chunks und Stripes erspare ich dem Thread … doch nicht:

Chunks: Ein Datenblock (engl. data block) ist eine begrenzte, fallweise festgelegte Anzahl von Bits oder Bytes, die als Transporteinheit behandelt wird. Der Blockaufbau und die Blockelemente entsprechen den betreffenden Kommunikationsprotokollen.
>>> Das bedeutet, das Chunks Transporteinheiten darstellen, die von Protokoll zu Protokoll, von Applikation zu Applikation verschieden sein können.

Stripes: Die Stripe Size bezeichnet die Größe des aus einem oder mehreren Datenblöcken (Chunks) bestehenden Datenbereichs (Striping-Granularität), der auf die RAID-Speichermedien verteilt wird. So wird bei einem aus vier Festplatten bestehenden Array mit einer Stripe Size von 1 MiB ein Datenblock (Chunk) in einer Größe von 256 KiB auf jede Festplatte geschrieben. Bei einer Vergrößerung der Stripe-Size wächst der maximale Durchsatz, gleichzeitig erhöht sich aber die Zugriffszeit. Heute üblich sind Stripe-Größen von 256 KiB bis 2 MiB.
>>> Und diesen Absatz in der deutschen Wikipedia halte ich für falsch, denn Stripes werden nicht verteilt, sondern auf einem Disk als ganzes geschrieben/gelesen!
Vergleiche:
–> http://en.wikipedia.org/wiki/Standard_RAID_levels
–> http://en.wikipedia.org/wiki/RAID

>>> Chunks werden selbstverständlich Controller-intern benutzt. Und vom (Kernel-) Treiber. Aber sie erblicken selten das Licht der Welt in Form von Dokumentationen …

Siehe auch hier:
–> http://www.adaptec.com/blog//2006/06/05/picking-the-right-stripe-size/

Sc0rp

Also bei mir läuft auf einem Raid 5 (5 Festplatten á 1TB) seit einem Jahr ext4 stabil

Der Wikipedia Eintrag sollte richtig sein. Ein Chunk ist das was du bei einem Raid am Stück auf der Platte liegen hast. Ein Stripe (-> Streifen) ist (wenn man sich das Raid quasi als Tabelle vorstellt wobei jede Spalte eine Festplatte darstellt) genau eine Zeile. Jede Tabellenzelle wäre dann ein Chunk.
Stride ist dann eben wie du geschrieben hast: chunk-size/Blockgröße.

Quelle wäre z.B. hier und Wikipedia hast du ja selber schon zitiert. Schau dir mal Dokumentationen/Hilfen/Tutorials zu Software Raid an, denn da kann man das alles einstellen und wird fast überall auch beschrieben.

Zoldan;450594 said:
Quelle wäre z.B. hier und Wikipedia hast du ja selber schon zitiert. Schau dir mal Dokumentationen/Hilfen/Tutorials zu Software Raid an, denn da kann man das alles einstellen und wird fast überall auch beschrieben.

Das ist genau das, was ich oben geschrieben hab: Chunks sind Applikationsabhängige Datenblöcke – im Sinne des Software-RAIDs also richtiger. Allerdings heisst der Terminus im RAID-Verbund “Stripe-Size”.Die ersten beiden Absätze der Dokumentation verdeutlichen das:[Spoiler]Mit dem Chunk-Size Parameter legt man die Größe der Blöcke fest, in die eine Datei zerlegt wird, die auf einen RAID-Verbund geschrieben werden soll. Diese ist nicht mit der Blockgröße zu verwechseln, die beim Formatieren des RAID-Verbundes als Parameter eines bestimmten Dateisystems angegeben werden kann. Vielmehr können die beiden verschiedenen Blockgrößen variabel verwendet werden und bringen je nach Nutzung unterschiedliche Geschwindigkeitsvor- wie auch -nachteile.>>> Ersetze einfach “Chunk” durch “Stripe” und du bist beim normalen RAID-Terminus! Und genau hier steht auch: Chunk-Size <> FS-Block-Size, deshalb gibt es den Schalter “-E stride=x”!Nehmen wir das Standardbeispiel: RAID-0 (/dev/md0) bestehend aus /dev/sda6 und /dev/sdb6 soll als angegebene Chunk-Size in der /etc/raidtab 4 kB haben. Das würde heißen, daß bei einem Schreibprozeß einer 16 kB großen Datei der erste 4 kB Block und der dritte 4 kB Block auf der ersten Partition (/dev/sda6) landen würden, der zweite und vierte Block entsprechend auf der zweiten Partition (/dev/sdb6). Bei einem RAID, das vornehmlich große Dateien schreiben soll, kann man so bei einer größeren Chunk-Size einen kleineren Overhead und damit einen gewissen Performancegewinn feststellen. Eine kleinere Chunk-Size zahlt sich dafür bei RAID-Devices aus, die mit vielen kleinen Dateien belastet werden. Somit bleibt auch der »Verschnitt« in einem erträglichen Rahmen. Die Chunk-Size sollte also jeder an seine jeweiligen Bedürfnisse anpassen. >>> Und hier zeigt sich “Chunk-Size” == “Stripe-Size” == 4KiB (der Block der auf EINE Disk als Ganzes geschrieben wird, der nächste kommt auf die nächste Disk bis reihum verteilt wurden! [/spoiler]

Zoldan;450594 said:
Der Wikipedia Eintrag sollte richtig sein. Ein Chunk ist das was du bei einem Raid am Stück auf der Platte liegen hast. Ein Stripe (-> Streifen) ist (wenn man sich das Raid quasi als Tabelle vorstellt wobei jede Spalte eine Festplatte darstellt) genau eine Zeile. Jede Tabellenzelle wäre dann ein Chunk.Stride ist dann eben wie du geschrieben hast: chunk-size/Blockgröße.

Und der Absatz ist inhaltlich falsch. Schau dir die englischen Einträge an! Eine Zeile wäre in der Tabellen-Analogie ein Stripe-Set.Das (abhängig vom RAID-Level) aus Datenblöcken und Parity-Blöcken bestehen kann.Sc0rpps: ich geh auch mal wieder arbeiten: ALT + TAB 😉

Sc0rp;450597 said:

Zoldan;450594 said:
Der Wikipedia Eintrag sollte richtig sein. Ein Chunk ist das was du bei einem Raid am Stück auf der Platte liegen hast. Ein Stripe (-> Streifen) ist (wenn man sich das Raid quasi als Tabelle vorstellt wobei jede Spalte eine Festplatte darstellt) genau eine Zeile. Jede Tabellenzelle wäre dann ein Chunk.
Stride ist dann eben wie du geschrieben hast: chunk-size/Blockgröße.

Und der Absatz ist inhaltlich falsch. Schau dir die englischen Einträge an! Eine Zeile wäre in der Tabellen-Analogie ein Stripe-Set.
Das (abhängig vom RAID-Level) aus Datenblöcken und Parity-Blöcken bestehen kann.

Es hat mir einfach keine Ruhe gelassen …

Folgendes Gedankenexperiment:
Wenn man von dem Wikipedia-Absatz ausgehen würde und ein fünf (5) Festplatten-RAID-Verbund betreiben würde, welche Stripe-Size müsste der Controller einem anbieten? Auf der “Chunk-Size” in der Potenz zu zwei basierend: 20480 (5*2^2*1024),40960,81920 …
Die kleinste Stripe-Size wäre dann 2560 (Byte) = (5*512byte).

* Habt ihr schon mal einen Controller erlebt, der Euch solche Stripe-Size-Werte anbietet?

* Ändern sich die Stripe-Sizes per Setup? (Nein! Nicht mal beim Software-RAID)

Aber nun rechnet mal anders herum: wenn ein RAID eine Stripe-Size von 64k hat und diese auf 5 Festplatten verteilen soll, wie gross ist
dann ein (Wikipedia-) “Chunk”?
Antwort: 64*1024byte / 5 = 13107,2byte -> Wie soll das gehen?

@Zoldan: Wem glaubst du nun mehr? Wikipedia oder dem RAID-Verrückten? (dem Spinner der fünf RAID-Controller besitzt, einer davon wassergekühlt *hr hr hr*)

Sc0rp

Du widersprichst dir da gerade selber. Die Lösung hast du weiter oben schon verraten.

Sc0rp;450705 said:
@Zoldan: Wem glaubst du nun mehr? Wikipedia oder dem RAID-Verrückten? (dem Spinner der fünf RAID-Controller besitzt, einer davon wassergekühlt *hr hr hr*)

Ich glaube mir selber und nicht dem Verrückten (dem Spinner der mit seinen 5 Raidcontrollern auf die Kacke haut). Man gibt eine chunk-size an und den Rest errechnet mkfs sowieso automatisch.

[SIZE=”5″]Partitionierung von grossen RAID-Sets[/SIZE]

Grundsätzlich gibt es zwei Möglichkeiten:
a) “normale Partitionierung” ala parted/(s)fdisk etc. (vergleiche “optimales Alingning von RAID-Sets”)
b) LVM (mit PV auf Physical Disk)

zu a)
Partitionierung mit MBR (MS-DOS) ist möglich, aber mit erheblichen Einschränkungen:
Vorteile:
– altbekannt und verbreitet

Nachteile:
– max. 8TiB addressierbar (–> http://de.wikipedia.org/wiki/Master_Boot_Record#Partitionstabelle)
– Alingment-Problem(e):
-> 512Byte Sektor vs. FS-Blocksize vs. Stripsize
-> Bootsektor (siehe “optimales Alingning von RAID-Sets”)
-> Kompatibilitätsproblem (“Erster Track”):
[spoiler] –> http://insights.oetiker.ch/linux/raidoptimization.html
[code]
# sfdisk -l -uS /dev/sda

Disk /dev/sda: 243152 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sda1 * 63 996029 995967 83 Linux
[/code]
Hard disk partitions in the PC world are normally aligned to hard disk tracks. This made perfect sense about 1’000 years ago, when this information had something to do with the physical layout of a hard disk. These days, though, cylinders, tracks and heads are pure fantasy, carried along for the benefit of DOS compatibility.
Ever wondered what this disk would look like, physically?

– Per Default werden in fdisk wegen der Abwärtskompatibiltät das MBR-Schema und der “erste Track” benutzt
-> die erste Partition fängt bei Sektor 63 an (0-62 werden also freigehalten)
-> 63 Sektoren sind keine 2er Potenz -> daher werden alle “Stripes” ab einer Grösse von 1KiB versetzt (misaligned) geschrieben
-> das bedeutet ein Verlust von mind. 30% Performance und zusätzliche Plattenarbeit
-> vergleichbar mit dem Read-Modify-Write (RMW)-Problem beim AFT
[/spoiler]

Partitionierung mit GPT: besserer Ansatz da 48Bit-LBA basiert
– basiert komplett auf LBA (=> keine Probleme durch C/H/S-Adressierung!)
– bis 128 PiB adressierbar (bei 512Byte Sektoren und 48Bit LBA)
– Alingment-Problem (vergleiche “optimales Alingning von RAID-Sets”)
-> 512Byte Sektor vs. FS-Blocksize vs. Stripsize
-> Bootsektor (siehe “optimales Alingning von RAID-Sets”)

zu b)
LVM2 Ansatz nach O+P Insights (–> http://insights.oetiker.ch/linux/raidoptimization.html)
Vorteile:
– keine Partitionierungsaltlasten (“erster Track”/LBA vs. C-H-S)
– alle Vorteile des Volume-Managements
Nachteile:
– keine bekannt (bitte um Wortmeldungen!)

Detailinformationen:
– PV wird direkt (sprich ohne Partionierung!) auf dem “physical disc” (dem “Volume-Set” des RAID-Controllers) angelegt:
[code]
pvcreate –metadatasize 4M /dev/sdx
[/code]
– Metadaten werden zum Speichern und Verwalten der (Logical-/Physical-) Volumes benötigt
-> Metadaten belegen per Default die ersten 192KiB jedes PV’s, dann geht es mit den “Physical Extends” los
-> diese Größe kann für eine grosse Anzahl von LV’s/PV’s zu klein sein, daher am besten gleich die –metadatasize auf 4MiB setzen (entspricht einem “Physical Extend”)
– LVM nutzt per Standard 4MiB grosse “Extends” -> kein Alingment-Problem (da für alle Stripe-Sizes passend) (–> http://www.markus-gattol.name/ws/lvm.html#sec11)
[spoiler]
With LVM2, there is no limit on the maximum numbers of extents per PV respectively LV. The default extent size is 4 MiB, and there is no need to change this for most configurations, because there is no I/O (Input/Output) performance penalty for smaller/bigger extent sizes. LVM tools usage, however, can suffer from high extent count, so using bigger extents can keep the extent count low. We need to be aware, that different extent sizes can not be mixed in a single VG, and changing the extent size is the single unsafe operation with the LVM i.e. it can destroy data. The best advice is to stick with the extent size chosen in the initial setup.[/spoiler]
– kein “reservierter Bootsektor”, daher kein Sektorversatz (siehe “optimales Alingning von RAID-Sets”)
– max. 8EiB (bei 64bit-CPU’s und 4MiB Extends) addressierbar (–> http://www.tldp.org/HOWTO/LVM-HOWTO/lvm2faq.html:)
[Spoiler]
4.1.13. What is the maximum size of a single LV?
The answer to this question depends upon the CPU architecture of your computer and the kernel you are a running:
* For 2.4 based kernels, the maximum LV size is 2TB. For some older kernels, however, the limit was 1TB due to signedness problems in the block layer. Red Hat Enterprise Linux 3 Update 5 has fixes to allow the full 2TB LVs. Consult your distribution for more information in this regard.
* For 32-bit CPUs on 2.6 kernels, the maximum LV size is 16TB.
* For 64-bit CPUs on 2.6 kernels, the maximum LV size is 8EB. (Yes, that is a very large number.)
(Anmerkung Sc0rp: Diese Angaben beziehen sich auf 4MiB-Extends)[/spoiler]

AFT (4k-Sektoren) Problematik
– Advanced Format Technology bedeutet, das 8*512Byte Sektoren auf einem 4KiB Festplattenhardwaresektor abgebildet werden
-> dem System werden 512Byte-Sektoren vorgegaukelt, geschrieben werden 4069Byte (8*512Byte) am Stück!
-> Read-Modify-Write (RMW)-Problem (–> http://www.tomshardware.de/Western-Digital-EARS,testberichte-240496-3.html – Absatz “Die Performance-Falle”)
-> besondere Vorsicht beim Partitionieren ist grundsätzlich geboten (native Unterstützung ab Windows Vista SP1 und Linux Kernel 2.6.3x)
-> grundsätzlicher Rat: Partitionierungsschema auf Werte anpassen, die durch acht (8) teilbar sind (und 2er Potenzen dann ergeben)

– Ressourcen:
–> http://lwn.net/Articles/377897/
–> http://www.tecchannel.de/storage/komponenten/2031303/mehr_kapazitaet_und_neue_probleme_festplatten_mit_advanced_format/
–> http://www.ibm.com/developerworks/linux/library/l-4kb-sector-disks/

*ToDo*

@drdope: bitte noch nicht übernehmen

[SIZE=”5″]@Community: Brauchen noch Erfahrungen und Wortmeldungen (“Ressourcen”)![/SIZE]

Sc0rp

[SIZE=”1″]
Changelog:
20110401-2009 : GPT-Absatz überarbeitet (Typos/Formatierung)
20110401-2012 : GPT-Absatz überarbeitet (Formatierung)
20110404-1639 : erste Überarbeitung / Metadata@LVM2 eingepflegt / Infos zu AFT eingepflegt
[/SIZE]

Dateisystemtabell überarbeitet:

[table=”head”] Dateisystem | max. Dateigröße | max. Dateisystemgröße
EXT3 | 16 GiB to 2 TiB [6] | 2 TiB to 32 TiB
XFS | 8 EiB [29] | 16 EiB [29]
EXT4 | 6 GiB to 16 TiB [6] | 1 EiB
BTRFS | 16 EiB | 16 EiB
[/TABLE]

BB-Code für Tabellen siehe:
–> http://www.meisterkuehler.de/forum/ankuendigungen-and-informationen/20277-vorstellung-neue-funktionen-and-optionen-forum.html#post315325

@drdope: Bitte übernehmen Sie! 😉

Sc0rp

drdope;451654 said:
Hab die Sachen inzwischen reinkopiert;[…]

Okay 😉

Ich werde mich nun dem Teil “optimales Alingning von RAID-Sets” widmen und mal schauen ob ich das übersichtlich/verständlich gestalten kann …

Dazu muss ich mich ersma in GPT vergraben, das MBR Thema hab ich ja schon grösstenteils abgearbeitet. Und parted muss ich zwecks “alinging” auch noch durchleuchten …

Feedback wäre schön!
– Was ist noch unverständlich?
– Wo fehlen Details?

Sc0rp

ps: wenn ich diese Woche noch’n bissel Zeit hab, werde ich mal meine AFT-Samsung mit Linux “bearbeiten”, mal sehen was mir da fdisk/parted anbietet. Dann schreibe ich was zum Thema fdisk/parted im Speziellen.

Optimales Aligning von RAID-SetsAlignment – Was bedeutet das?Alle Daten in der EDV sind blockorientiert: sie werden als Blöcke bzw. Chunks transportiert, verarbeitet und abgelegt. Leider gibt es dazu kein einheitliches Kozept!Und so kommt es, das unterschiedliche Geräte bzw. Software unterschiedliche Blockgrössen benutzten und diese auch unterschiedlich organisieren.Mittels dem “optimalen Alignment” versucht man alle Blöcke deckungsgleich zu bekommen, sodass niemals zuviele oder sogar die falschen Blöcke benutzt werden, das bedeutet nämlich auf jeden Fall Performanceverlust!Welche Blöcke sind interessant?Zuerst betrachten wir mal die Festplatte selber:- Sie ist in Einheiten von 512Byte eingeteilt (Sektoren) – und das schon seit ihrer Zeitrechnung (very old!)- Zusätzlich zu diesem vom Computer nutzbaren Datenblock werden pro Festplattensektor noch ein GAP- und ein ECC-Feld gespeichert.- Um die Verschwendung von Platz durch unzählige GAP’s und ECC’s einzudämmen, wurde AFT 2008 von der IDEMA verabschiedet und findet seit 2010 in fast allen Festplatten Verwendung.- Mit AFT gibt es einen neuen ‘Blocklayer’: 4k (8x512Byte)Darauf muss man achten/Alignment-Issues:-> Alle Partitionen sollten auf 4k ausgerichtet sein (Anfänge sollten durch 4096Byte bzw. 8 Sektoren teilbar sein)-> Gilt (noch) nicht für RAID-Controller, da AFT die nötigen 512Byte-Blöcke emuliert, ABER:Darauf setzt der RAID-Controller seine Stripe-Size auf:- Üblicherweise zur Potenz Zwei (2^x)- Areca kann noch nicht nativ mit AFT umgehen (auf 512Byte basiert!)- Stripe-Size kann man (grob) auf den Anwendungszweck anpassen:[Spoiler]–> ARECA-Manual v4.1, Seite 54A larger stripe size produces better-read performance, especially if your computer does mostly sequential reads. However, if you are certain that your computer performs random reads more often, select a smaller stripe size.Anmerkung: Bitte mit Vorsicht geniessen, das ist sehr allgemeingültig! [/spoiler]Darauf muss man achten/Alignment-Issues:-> RAID-Controller basieren (Stand heute) auf 512Byte-Sektoren, und können nicht nativ mit AFT umgehen!-> Daraus erwächst sich das Problem, das man nicht weiss, an welchem Sektor der Controller mit einem Stripe beginnt!-> Bei Areca-Controllern befindet sich der DCB in einem 4KiB-Raster, es gibt hier also KEIN RMW-Problem bei AFT@512e-Modus-> Es wird empfohlen, die Stripe-Size nicht zu klein zu wählen (64KiB/128KiB/256KiB), im Regelfall einfach den Controller-Standard benutzen!Darauf setzt die Partitionierung auf:- LVM strukturiert seine Datenträger in 4MiB grosse “Extends” (das passt eigentlich zu allen Stripe-Sizes)-> am Anfang kommen die Metadaten- GPT basiert auf LBA (wobei ein “Logical Block” ein Festplattensektor ist)-> GPT’s erste Partition beginnt bei LBA 34 (34*512Byte = 17408 Byte)Darauf muss man achten/Alignment-Issues:-> bei LVM sollte es keine Probleme geben, –metadatasize ggf. anpassen:–> Standard –metadatasize sind 192Kib, welche auf 64k-Stripes und darunter passt–> Besser –metadatasize auf 4MiB setzen, dann kann man a) alle Stripe-Sizes benutzen und b) hat man eine komplette Einteilung in 4MiB-Blöcke-> bei GPT sollte man darauf achten, das die erste Partiton bei einer Stripe-Size Grenze beginnt (Sektoren muss man dann selber errechnen: Anfangs-Sektor = Stripe-Size / 512Byte) – kommen AFT-Festplatten zum Einsatz zusätzlich den Faktor Acht (8*512Byte) beachten!Darauf setzt dann das Dateisystem auf:- Üblicherweise wird das Dateisystem in Blöcken zu je 4096Byte organisiert-> XFS: 512 Byte bis 64 KiB Blockgöße, 4096Byte sind Standard-> EXT3: 1024KiB bis 8KiB Blockgröße, 4096Byte sind Standard-> EXT4: *unbekannt*, 4096Byte sind Standard-> BTRFS: *unbekannt*, *unbekannt*Darauf muss man achten/Alignment-Issues:-> Grundsätzlich sollte man keine Stripe-Sizes kleiner FS-Blocksize einsetzen-> 4KiB FS-Blocksize ist ein sehr guter Standard, da auch der Kernel mit 4K-Pages arbeitet-> Stripe-Sizes errechnen mit: FS-Blocksize (gewünscht) * 2^xSofern man nun alle Blockgrössen auf einander abstimmt, bekommt man ein durchgehend performantes Dateisystem! Der Idealfall wäre, wenn man die 4k-FS-Blöcke direkt auf die AFT-Sektoren (8*512Byte) abbilden würde und dies deckungsgleich in das Stripe-Size-Rasters des RAID-Controllers bekäme. Dann hätte man im Speichersubsystem keinerlei systemische Probleme und kann sich der 100%igen Performance sicher sein.Meine Empfehlung zum Aufbau wäre also:- ein RAID-Set mit Stripe-Size 64Kib/128KiB/256KiB (RAID-Level 5 oder 6), der Controller-Standard ist empfehlenswert[spoiler]Ich vermute, das die Controller eine Lieblings-Stripe-Size haben, auf die die RAID-CPUs optimiert sind, leider kann ich das mangels Dokumentation nicht “beweisen”.[/spoiler]- darauf ein LVM2 (siehe unter Partitionierung) mit –metadatasize=4M– darauf ein XFS anlegen (Erstellung und Mounten siehe entsprechende Bereiche) @drdope: bitte noch nicht übernehmen 😉 *muahaha*(ich hab diesmal versucht weniger vor zu formatieren – der Text ist hoffentlich übersichtlich)Ich muss noch den Areca-Support mit Fragen löchern:- insbesondere das Problem des “RAID-MBR” bzw. DCB (DiskControlBlock): wie lang, bzw. bei welchem Sektor fängt das erste Stripe an?- ob der RAID-Core auf bestimmte Stripe-Sizes ‘optimiert’ ist(Adaptec natürlich analog, wer einen 3Ware besitzt könnte das bitte bei LSI gleichfalls anfragen!)Sc0rp

Mal ne Frage Bezieht sich das Ganze Thema um Speicherkapzität von Linuxsystem also wie man einer Festplatte im Linuxstyle Formatiert um besser Preformens zu bekommen? Für Fileserver?

:-k Bin mal wieder Fassungslos Begeister was man hier im Forum Lernen kann (wenn man es versteht:+)

Re,

drdope;451729 said:
@sc0rp:
Hab deinen Beitrag (zur Partitionierung) noch etwas modifiziert; lese mal bitte Korrektur; […]

*DONE* Fazit: sehr gut formatiert (sehr übersichtlich!) – Keine Fehler gefunden …

Bitte noch hinzufügen:

Episode I: Partitionierung von Raidarrays
-> 2. “moderne” Partitionierung mit GPT statt MBR
–> Vorteile

* GPT ist vollständig auf 64Bit ausgelegt, auch wenn derzeit ‘nur’ 48Bit benutzt werden

drdope;451729 said:
Frau ist grad hier aufgeschlagen… will bespaßt werden…:)

*erm* :devil:

—-

Zaperwood;451731 said:
Mal ne Frage Bezieht sich das Ganze Thema um Speicherkapzität von Linuxsystem also wie man einer Festplatte im Linuxstyle Formatiert um besser Preformens zu bekommen? Für Fileserver?

*erm* Auf die “Spoiler-Buttons” kann man mit der Maus drauf klicken ;), dann sieht man die Erklärung unter “Hintergrund des Threads”.

Es geht um den Einsatz von Hardware-RAID-Controllern und die damit verbundenen zusätzlichen Überlegungen, die man anstellen sollte, um sämtliche auftretenden Problem zu umschiffen.
Ganz besonders wollen wir dem geneigten Leser einen Lösungsvorschlag im Sinne eines HOW-TO’s erarbeiten, der allen Nutzern von grossen RAID-Systemen effiziente Systeme ermöglicht.

(Ich hoffe ich habe das schön in zwei Sätze verpackt …)

Es bleibt jedem Selbst überlassen, in wie weit er das Wissen verwendet – viele Teile sind allgemeingültig (passen z.B. auch auf Software-RAIDs) und andere grundlegend (z.B. das Block- bzw. Alignment-Thema).

Und spezielle Fragen beantworten wir natürlich auch gerne!

Sc0rp

Okay danke Dir :d: jetzt vertstehe ich das ganze halbwegs
Habe die Überschrift nicht richtig mit dem Inhalt des Thema verknüpfen können

Nun will das Thema nicht mit Fragen zerstören
Over and Out

Werde aber Still Weiter Lesen:respekt:

Ich habe mal auf meinem MMPC (Heimserver) ein paar Tests gemacht:Setup:Festplatte: WDC WD15EVDS-63V (1,5TB, kein AFT!)OS: Ubuntu LTS 10.04.2 (einziges Betriebssystem)Partitionen: eine (keine Swap- oder Extra-Boot Partition(en))Vergleich:Das gebräuchliche fdisk:[spoiler][code]sc0rp@MMPC:~$ sudo fdisk -cu /dev/sdaBefehl (m für Hilfe): pPlatte /dev/sda: 1500.3 GByte, 1500301910016 Byte255 Köpfe, 63 Sektoren/Spur, 182401 Zylinder, zusammen 2930277168 SektorenEinheiten = Sektoren von 1 × 512 = 512 BytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0x00026ccb Gerät boot. Anfang Ende Blöcke Id System/dev/sda1 * 2048 2930276351 1465137152 83 LinuxBefehl (m für Hilfe): qsc0rp@MMPC:~$[/code][/spoiler]Erster Vergleichskandidat parted:[spoiler][code]sc0rp@MMPC:~$ sudo parted /dev/sdaGNU Parted 2.2Verwende /dev/sdaWillkommen zu GNU Parted! Geben Sie ‘help’ ein, um eine Liste der verfügbaren Kommados zu erhalten.(parted) printModell: ATA WDC WD15EVDS-63V (scsi)Festplatte /dev/sda: 1500GBSektorgröße (logisch/physisch): 512B/512BPartitionstabelle: msdosNummer Anfang Ende Größe Typ Dateisystem Flags 1 1049kB 1500GB 1500GB primary ext4 boot(parted) quitsc0rp@MMPC:~$[/code][/spoiler]Zweiter Vergleichskandidat sfdisk:[spoiler][code]sc0rp@MMPC:~$ sudo sfdisk –force /dev/sdaÃœberprüfe, dass niemand diese Festplatte zur Zeit benutzt …BLKRRPART: Das Gerät oder die Ressource ist belegtDiese Festplatte ist zur Zeit in Benutzung – Neupartitionierung ist vermutlicheine schlechte Idee. Hängen Sie alle Dateisysteme auf dieser Platte aus unddeaktivieren Sie alle Swap-Partitionen (mit swapoff).Benutzen Sie –no-reread, um diese Ãœberprüfung zu unterbinden.Festplatte /dev/sda: 182401 Zylinder, 255 Köpfe, 63 Sektoren/SpurAlte Aufteilung:Einheit = Zylinder von 8225280 Bytes, Blöcke von 1024 Bytes, Zählung beginnt bei 0 Gerät boot. Anfang Ende #Zyl. #Blöcke Id System/dev/sda1 * 0+ 182401- 182402- 1465137152 83 Linux/dev/sda2 0 – 0 0 0 Leer/dev/sda3 0 – 0 0 0 Leer/dev/sda4 0 – 0 0 0 LeerEingabe im folgenden Format; abwesende Felder erhalten einen Vorgabewert. Normalerweise brauchen Sie nur und anzugeben (undvielleicht )./dev/sda1 :sc0rp@MMPC:~$[/code][/spoiler]Dritter Vergleichskandidat cfdisk:[spoiler][code]sc0rp@MMPC:~$ sudo cfdisk /dev/sda–> Programm bringt Fehlermeldung:FATALER FEHLER: Beschädigte primäre Partition 0: Partition endet im letzten teilweisen ZylinderEine Taste drücken, um cfdisk zu beenden[/code][/spoiler]Wie man deutlich sieht, sind sich nichtmal die Programme einig, wie eine Festplatte *wirklich* partitioniert ist. Das hochgelobte cfdisk beschwert sich sogar über falsche Zylinder-Grenzen … möglicherweise liegt es aber auch daran, das Ubuntu die HD im MS-DOS-Kompatibilitätsmodus formatiert hat, aber anzeigen sollten alle trotzdem das Gleiche!Ich werde das mal weiter testen und berichten …EDIT: Update/Revisionparted und fdisk sind sich einig, wenn man richtig liest … :+fdisk sagt, das die erste Partition bei Sektor 2048 beginnt, das bedeutet, das die Sektoren 0-2047 (= 2048*512Byte = 1048576 Byte = 1024KiB) frei sind. Die erste Partition beginnt als bei 1048576Byte + 512Byte = 1049088, was parted korrekt als 1049kB (kilo nicht KiBi!) ausgibt.Fazit: fdisk macht seinen Job ordentlich, und bei parted gibt es zunächst “Umrechnungsprobleme” – am besten bei der Verwendung von parted erstmal ein[code](parted) unit s[/code]angeben, dann klappt es auch bei der Ansicht:[code](parted) printModell: ATA WDC WD15EVDS-63V (scsi)Festplatte /dev/sda: 2930277168sSektorgröße (logisch/physisch): 512B/512BPartitionstabelle: msdosNummer Anfang Ende Größe Typ Dateisystem Flags 1 2048s 2930276351s 2930274304s primary ext4 boot(parted)[/code]Sc0rp*puh* bin ich erleichtert, das das gut ausgegangen ist 😯

drdope;451848 said:
btw hab die LVM-Sektion noch mal überarbeitet, schau mal kurz drüber.
Ich hab einige Dinge aus den “Detailinfos” zu den Vorteilen gepackt, fand ich da besser aufgehoben.

*huh* hab gar keine Veränderungen gesehen – fallen zumindest nicht direkt ins Auge … möglicherweise bin auch schon Detailblind 😯

drdope;451848 said:
Die AFT-Problematik hab ich mal unter “V. Sonstiges” hinzugefügt, da sie imho nur indirekt zur Partitionierung gehört, oder wie siehst du das?

Ja, das ist in der Tat kniffelig:

Im Desktop-Bereich und im Software-RAID sollte man halt grundsätzlich darauf achten, da anscheinend alle seit 2010 produzierten Festplatten irgendwie AFT nutzen. Wenn man da nicht aufpasst, verliert das Speichersubsystem mind. 30% an Leistung, und das schon auf dem untersten Layer … da wundern sich bestimmt manche Leute zu Tode!
Daher Augen auf beim Partitionieren! Habe diverse Foren zu diesem Thema durchsucht und die einhellige Meinung ist: alles manuell machen! Und dem parted[i] Alignment-Check darf man auch nicht trauen …

Tja, das ist hauptsächlich ein Betriebssystem-Problem. Nicht alle können gleich gut mit GPT umgehen. Besonders das noch weit verbreitete und beliebte Windows XP (32bit) ist ein unbelehrbarer Störenfried ;). Unter Linux gibt es keinerlei EInschränkung -> also imm GPT nutzen:
MS-DOS-Kompatibilität abschalten mittels
[code]
fdisk -cu /dev/sdx
[/code]
[i]-c schaltet den MS-DOS-Kompatibiltätsmodus ab (braucht heute keiner mehr)
-u schaltet die Anzeige von C-H-S bzw. Tracks auf Sektoren um

Normalerweise bekommt man aber eine Warnung von fdisk beim Einsatz von modernen Kernel’s:
[code]
WARNING: DOS-compatible mode is deprecated. It’s strongly recommended to
switch off the mode (command ‘c’) and change display units to
sectors (command ‘u’).
[/code]

drdope;451848 said:
gibt mir mal ein “Make it so”, wenn ich den Alignment-Part einfügen kann…

Energie! (hab eben nochmal die Areca-Details dazu gefügt, die Adaptec-Details musst du dann später nachtragen …)

drdope;451848 said:
Ich hoffe ich komme auch mal dazu, noch was zum Thema Mountoptions/XFS zu schreiben, vor lauter editiererei…

Das hoffe ich auch – aber du hast noch grob 1,5 Monate Zeit, spätestens dann bekommt die BiGBOX ihr neues grosses Array (LVM/XFS)!

Sc0rp

drdope;451953 said:
Ich hab mein Array noch mal mit den entsprechenden parted Parametern aus deinem 2. Post gecheckt.

[CODE]megatron ~ # parted /dev/sdc
[…]
Nummer Anfang Ende Größe Dateisystem Name Flags
1 2048s 27343742975s 27343740928s xfs primary
[/CODE]

Das schaut doch imho ok aus…
128kB (Stripsize) / 512B (Sektorgröße) * 8 (AFT-“Korrekturfaktor”) = 2048

Man kann sich entscheiden, entweden in Bytes zu rechnen, oder in Sektoren:

[In Bytes]
2048 Sektoren * 512 Byte/Sektor = 1048576 Byte

*AFT-Check:
1048576 Byte / 4096 Byte = 256 => AFT passt 😉

*Stripe-Size-Check:
(1048576 Byte = 1024KiB)
1024KiB / 128KiB = 8 => Stripe-Size sollte auch passen!

[In Sektoren]
*AFT-Check:
2048 Sektoren / 8 (8*512Byte Sektoren pro AFT) = 256 => saubere Zweierpotenz bedeutet AFT passt

*Stripe-Size-Check:
128KiB / 512 Byte/Sektor = 256 Sektoren/Stripe => saubere Zweierpotenz bedeutet Stripe passt

drdope;451953 said:
Jetzt bin ich nur noch etwas ratloser hinsichtlich meiner Arrayperformance…

Welche “Perfomance-Probleme” hast du denn? Möglicherweise liegts an der inode64 Option … oder anderen “Mountoptionen” … ich glaube der Part fehlt noch für XFS 🙂

drdope;451953 said:
hab das Alignment jetzt auch hinzugefügt, schau mal drüber, habs ein bissl umgestrickt, so 100% gefällt mir das aber noch nicht… Vorschläge?

Jo, dafür muss ich mir diesmal mehr Zeit nehmen … und vorher mal was anderes machen … sonst platzt mir noch der Kopf vor lauter RAID-Gedöns.

Werde mich ersma
– meinem SCHLUMPF (Wohnzimmer-PC, WaKü-Vorbereitung)
– meinem SPIDAMAN (Router, PICMG ist anscheinend defekt)
– seinem Kollegen DSM (Backup-Rechner, wird aufgebaut)
– meinem ROCKY (Heimserver (Rev.2), fehlen nur noch’n paar Kabel)
– und endlich meinem ZOCKER (Workstation, Mainboard muss ersetzt werden plus MO-RA3 Erweiterung)
widmen – natürlich nach Frau und Kind / der Wohnung und dem Garten.

Ich warte auf deine Ergänzungen (XFS und/oder Mountoptionen) und bleibe (natürlich) am Thread dran, werde aber mal das Tempo rausnehmen – das wichtigste steht ja drin!

Sc0rp

Re,

drdope;452465 said:

@sc0rp
Performanceprobleme ist übertrieben, aber ich komme halt nur auf ca. 140-180MB/s; hab nach der Parted-Ausgabe eigentlich vermutet, es läge am falschen Alignment, aber dem ist ja wohl nicht so…
Naja, schaun wa mal.

Muhahaha, ich bin auf Arbeit (ALT+TAB) … und daher kann ich dazu gleich mal antworten 😉

Also man sollte immer das Gesamtkonzept beachten, klar klingen 140-180MB/s erstmal nicht viel (wenn man von der theoretischen Leistung von acht Festplatten ausgeht), aber was kann das Drum-Herum eigentlich leisten? Und da sieht es bei den Desktop-Boards im Vergleich zu Server-Boards schon anders aus, Server-Boards werden in der Regel auf durchgängige I/O-Leistung getrimmt, gut zu sehen an den Chipsätzen die da verbaut werden. Wichtig hierbei natürlich auch die Treiber-Geschichte: welche Arbeit lagert der Treiber wirklich an den Controller aus?

Ich finde deine Array-Leistung absolut okay, immerhin reden wir hier von einem “Standard-Setup”, sprich kein explizites Tuning. Mach mal den IOzone Test und den anderen *Name entfallen*, dann vergleichen wir nochmal … achja, und nen FTP-Durchsatz-Test zu einem anderen Host (bzw. mehreren, wenn du kannst) könntest du auch mal probieren.

Ich bin mal gespannt, welchen Durchsatz ich erreichen werde: zwischen meinem SUPAMAN (6×1,5TB/RAID6 an einem Areca 1120) und meiner BiGBOX (8x2TB/RAID6 an einem Areca 1160), beide sind mit 2x1GigabitEthernet (bonded) angebunden, per FTP – ich hoffe, ich bekomme rechtzeitig genügend Geld für die Festplatten zusammen (sieben fehlen noch :roll:)!

Sc0rp

ps: meine anderen Projekte gehen langsam voran … und diese Woche komme ich zu nix … ausser (vielleicht) zum Einkaufen. 🙁

Re,

littledevil;452481 said:
Wäre mal interessant was so ein Array unter Raid0 packt

Und unter RAID1(E) … japp, ich sollte mal eine komplette Testreihe über alle relevanten RAID-Level aufsetzen … wie gesagt, wenn ich endlich die Kohle bekomme/besitze werde ich spezielle für dich ein RAID0 Test anschubsen ;).

Sc0rp

ps: schöner wäre natürlich die Plattform von meinem Dad: X58er Gigabyte-Board und ‘nen i1880-12er Areca … ich versuch mal, da ran zu kommen, dann bekommt drdope auch einen Vergleichstest 😉

supi. Mit raid 0 kann man den engpaß besser eingrenzen. Außer mit SSDs mact raid0 aber selten sinn

Wäre mal interessant was so ein Array unter Raid0 packt

littledevil;452484 said:
supi. Mit raid 0 kann man den engpaß besser eingrenzen. Außer mit SSDs mact raid0 aber selten sinn

Muhaha, RAID0 – bis heute streiten sich die Profis, ob das überhaupt ein RAID-Level ist (das “R” bedeutet nämlich immernoch “redundant” ;)) – doch wo ist die Redundanz bei RAID0? :shock:Und die Krönung des Ganzen ist, das bei RAID0 die Fehlerwahrscheinlichkeit proportional zur Anzahl der Festplatten sinkt … und wenn ein Drive hin ist … Totalverlust!RAID0 macht nur bei (synthetischen) Performance-Messungen Sinn, umgangssprachlich “S.c.h.w.a.n.z.-Vergleich” – ansonsten bei Produktiv-Systemen nur in Kombination mit anderen Leveln. Das kommt dann stark auf den Einsatzzweck an! Und noch was: RAID 0+1 ist etwas anderes als RAID 1+0 …Da wir uns hier auf grosse Arrays zur Datenablage “spezialisieren”, betrachten wir vornehmlich RAID5 und RAID6.Sc0rp

Tagchen,

drdope;453062 said:
XFS-Mountoptionen hinzugefügt…. das war jetzt der erste Ansatzweise ruhige Nachtdienst…@sc0rp –> lies mal bitte drüber, ob alles ok ist, bin ein bissl Müde, evtl ist das eine oder andere ein wenig unelegant oder kompliziert formuliert…:(

*DONE*, liest sich gut, evtl. sind noch Typos drin (?) der neue Absatz sollte aber noch mit einem praktischen Beispiel ergänzt werden:[CODE]mount -t xfs -o inode64[,nobarriers] …[/CODE]bzw. das Pendant in der fstab (keine Ahnung wie es da aussieht). Die Mountoptions für EXT3 versuche ich mal nächste Woche zusammen zu stellen …

drdope;453062 said:
Hab die RE2 GPs schon zu Hause liegen; dummerweise nächste Woche den Kalender voll und ab Ostersamstag wieder 6 Nachtdienste….Moep!:(

Dafür hat uns der liebe Gott den Remote-Zugriff gegeben ;), mal ‘ne Stunde Platten in die Wechselrahmen schrauben muss drinn sein! Tests kann man dann über Nacht machen (lassen) … da verliert man keine Zeit für andere (wichtige) Dinge …Sc0rpps: meine Projekte liegen erstmal auf Eis :roll:, Garten ist wichtiger …

Hey Leute,

super sache dieser Thread, vielen dank das ihr euch die Mühe macht!
Ich werde in der nächsten Zeit mein 4 Platten RAID 5 zu einem 8 Platten RAID 6 ausbauen und so meine Kapazität von 5,45TB auf 10,8 TB erweitern. Da kann ich diese Tipps hier super für nutzen! Danke!

drdope, du hattest ja Ahnung von den 3ware 9650SE Controllern, wie lange wird meiner in etwa Brauchen um das RAID 6 aus 8 x 2 TB zu builden? Ich weiß nämlich nicht mehr wie lange das Builden damals gedauert hat, ich weiß nur noch, das das verschlüsseln von 5,45TB um die 50-60h gedauert hat.

MfG DrDoom

Vielen dank für die schnelle antwort :)Ich find das alles aber irgendwie ganz schön viel, ich meine es dauert gut und gerne 9 Tage von RAID Build + Verschlüsseln + Dateisystem erstellen. und zwar non stop Rechenzeit. Nun hab ich aber ein Verhältnismäßig kleines RAID. bei 24 mal 3 TB was heute schon kein problem ist .. dauert das ja 40 Tage, wenn wir von einer annährernden Proportionalität zwischen Kapazität und Zeit ausgehen. Oder Steigt die Leistung mit zunehmender Anzahl an Laufwerken auch? Weil ich kann mir nich vorstellen das der Controller wenn 24 Laufwerke dran hängen aufeinmal schneller wird nur weil die Bandbreite in folge der Laufwerkanzahl ansteigt.Worauf ich hinaus will. 40 Tage sind ne Menge Holz, da muss was passieren, weil wenn wir in ein paar Jahren 5-10TB Laufwerke haben, dann, können wir ja schlecht ein halbes Jahr warten, um das Array in betrieb zu nehmen!?!?!MfG DrDoom

Hallo DrDoom und drdope (nur Akademiker hier …:+)

Mein RAID6 auf 6×1,5TB hat knapp 6h gedauert … nur der Build.

Das Problem, das Übertragungsgeschwindigkeit und Plattenkapazität im Laufe der Jahre stark auseinander gedriftet sind, wurde schon mal in einem Artikel behandelt – anscheinend braucht aber der Markt mehr Kapazität als Speed, sonst würde die Entwicklung anders verlaufen ;).
-> Man arbeitet ja dran – mit SSDs. 😉

Und ja, theoretisch wird ein RAID immer mit steigender Anzahl von Festplatten schneller, je nach RAID-Level betrifft das die I/O-Leistung, die Lese- und/oder Schreibgeschwindigkeit (verteilt oder nacheinander) und andere Parameter (z.B. Stromverbrauch: mehr Watt pro Sekunde ;)).
-> Die Frage ist nur, ob man auch Systeme hat, die den entsprechenden Speed abnehmen können …

Theoretisch sollte der Build eigentlich nicht länger als 8h dauern (bei 2TB/Festplatte), da ja auf alle Festplatten gleichzeitig geschrieben wird!
-> Ich lehne mich mal weit aus dem Fenster und rechne mal 1,5TB in 6h macht 66,23MiB/s durchschnittliche Schreibrate … und das sollte auch bei anderen Festplatten hinkommen (okay, 7.200er sollten etwas schneller sein).

OCE (Online Capacity Expansion) dauert logischerweise länger (kann man sicher auch irgendwie berechnen) und ORM (Online RAID Migration) natürlich auch …

Sc0rp

und warum hattest du den Write-Cache deaktiviert? sollte man das an einem 3ware machen?

Guten Morgen,Sorry das ich so viele Fragen hab!Jetzt stell ich mir dir frage, wieviel performance es kostet den Write-Cache und um ganz sicher zu gehen auch noch den HDD-Cache zu deaktivieren. Und die zweite Frage, kann man an einem 3ware controller überhaupt den HDD-Cache deaktivieren? ich könnte mir vorstellen, das man das in der Firmware der Platte machen muss, und das klingt für mich doch ziehmlich gefährlich.Und dann noch eine frage, mein storage server ist nur 2-3 mal im monat an, um die aktuellen Backups zu fahren. und das auch nur für ein paar stunden. Bisher ist es noch nicht vorgekommen, dass genau in der zeit ein stromausfall ist. Bei einem 24/7 system würde ich das anders sehen. Wenn ich jetzt das für meinen fall anpasse, und hdd und write-cache an lasse, und es kommt doch mal zu einem GAU und der strom is weg. dann sind doch nur die daten weg die zu dieser zeit in den caches waren, sprich das aktuelle backup ist korrupt, und ich kann es wen der strom wieder da ist einfach noch mal kopieren oder?MfG DrDoom

Guten Morgen,

DrDoom;456312 said:
Sorry das ich so viele Fragen hab!

Ist entschuldigt … gerade so!

NEIN – Quatsch: Fragen ist erlaubt, ja sogar ERWÜNSCHT!

DrDoom;456312 said:
Jetzt stell ich mir dir frage, wieviel performance es kostet den Write-Cache und um ganz sicher zu gehen auch noch den HDD-Cache zu deaktivieren.

Nunja, das hängt natürlich individuell von deinem System ab, aber drdope hat dazu ein paar Werte …
Write-Cache ist HDD-Cache (dafür wird der nämlich hauptsächlich verwendet) und ist der zweite Cache in der Hierarchie: OS-Cache -> Controller-Cache -> Festplatten-Cache. Bei einem Stromausfall hat man also gleich an drei Stellen Verlust …
Die einzig sinnvolle Lösung für das Dilemma ist eine USV (engl. UPS), das steht sogar schon in dem Manual meines ersten RAID-Controllers (Intel SRCS16) als “highly recommended”. Daten verliert man bei einem Powerloss immer …

DrDoom;456312 said:
Und die zweite Frage, kann man an einem 3ware controller überhaupt den HDD-Cache deaktivieren? ich könnte mir vorstellen, das man das in der Firmware der Platte machen muss, und das klingt für mich doch ziehmlich gefährlich.

Man kann den HDD-Cache per Software-Befehl deaktivieren, das beherrschen eigentlich alle RAID-Controller – aus Sicherheitsgründen.
(Für das spezielle Doing bitte an drdope wenden)

DrDoom;456312 said:
Und dann noch eine frage, mein storage server ist nur 2-3 mal im monat an, um die aktuellen Backups zu fahren. und das auch nur für ein paar stunden. Bisher ist es noch nicht vorgekommen, dass genau in der zeit ein stromausfall ist. Bei einem 24/7 system würde ich das anders sehen.

Diese Annahme ist sehr gefährlich, denn ein ‘echter’ Powerloss tritt genau dann auf, wenn man es am wenigsten braucht … und man weiss nie, was der alles zu Boden reisst (Spannungsspitzen sind meistens auch dabei).

DrDoom;456312 said:
Wenn ich jetzt das für meinen fall anpasse, und hdd und write-cache an lasse, und es kommt doch mal zu einem GAU und der strom is weg. dann sind doch nur die daten weg die zu dieser zeit in den caches waren, sprich das aktuelle backup ist korrupt, und ich kann es wen der strom wieder da ist einfach noch mal kopieren oder?

Ja und Ja. Allerdings musst du vorher auf jeden Fall das Dateisystem wieder syncen … das dauert auch seine Zeit. Und wenn du ganz Pech hast, musst du vorher noch eine ausgefallene Festplatte ersetzen, das dauert nochmal …

Meine Empfehlung: kleine USV kaufen, die federt alles ab. Und solange man keine 19 Zoll Version braucht, sind die auch recht günstig. Man könnte sie ja auch für andere Hardware verwenden und einfach den Storage-Server zusätzlich dranhängen … das ist es gleich ein doppelter Zugewinn.

Sc0rp

Re,
Tja, wofür Hardware gebundene Caches verwendet werden, weiss nur der Controller, an dem Sie angeflanscht sind, wirklich. Alles Andere ist Spekulation. Sicher werden Sie zum Zwischenspeichern von Daten verwendet, aber wofür und wie viel im Einzelnen …

Festplatten-Caches und RAID-Controller-Caches sind sich dabei sehr ähnlich! Wenn man den Controller-Cache mangels BBU (Battery Backup Unit) betreibt und dadurch den “Write through”-Modus benutzt, hat man a) den “Write-Cache” ausgeschalten und b) benutzt man dann den Controller-Cache als Readahead-Cache. Soweit zur Theorie ;), denn der Controller muss ja auch die Paritätsdaten berechnen, und das tut er mit Sicherheit im RAM (=Controllercache), und sicher wird er dort auch ein “Reordering” machen (Daten-Stripes mit Paritäts-Stripes mischen) – wenn man das mal betrachtet und den “Write-Cache” deaktiviert, kann man sich vorstellen, welche Performance-Einbußen da lauern …

Jeder Cache hat natürlich seine Vorteile, insbesondere Geschwindigkeit! Daher wie gesagt, alle aktivieren und USV benutzen 😉

Sc0rp

Danke für die ausführliche Antwort!

Ich glaube, dann hab ich das noch nich so richtig verstanden.
Mein 3ware 9650 hat 256MB DDR ECC RAM. Aus dem Manual habe ich verstanden, dass dieser RAM für den Write-Cache verwendet wird, sprich der Controller-Proz lagert dahin Daten aus wenn die Platten nicht hinterkommen mit dem schreiben. HDD-Cache ist wie der Name schon sagt auf dem HDD-Board verlötet und wird von der Festplatte verwaltet. Die Festplatte benutzt diesen Speicher als Zwischenspeicher wenn sie mal nich hinterher kommt mit dem ablegen der Daten, oder aber auch, wenn die festplatte sektoren sortiert. dann wird dieser platz auch dafür verwendet.

Ich hab mal gelesen bzw. glaube mich daran zu einnern, dass
die Festplatte sich selbst überprüft und wartet. Wenn sie einen Sektor bzw. Block lange nich mehr in der “Hand” gehabt hat, und gerade mal nichts zu tun hat, dann ließt sie diesen Block aus, schreibt ihn in den Cache, nullt den Block, und beschreibt ihn wieder neu, bzw. schreibt die Daten in einen anderen Block, und lässt die ursprünglichen Block erstmal wieder leer.
Ist das richtig so?

MfG DrDoom

Hallöchen an alle,Platten sind gekommen, werde also wenn ich mal ein paar Minuten Zeit hab loslegen. Um mir Testzeit zu sparen würde ich gerne auf die die Erfahrung von drdope zurück greifen.Mit wie viel I/O Verlust muss ich rechnen, wenn ich alle Caches deaktiviere? Da ich eh komplett verschlüssel, ist mein proz der Flaschenhals in meinem System, und ein neuer ist vorerst nich in sicht… Mein System schreibt und ließt mit 50-60MByte/s und das reicht mir vollkommen aus. Wenn durch die Deaktivierung des Write-Cache und HDD cache jetzt natürlich alles auf unter 50MByte/s fällt, wäre das natürlich doof.Hat mal einer von euch ein RAID 5 mit 8 Platten aus I/O-sicht mit einem RAID 6 aus 8 Platten verglichen? unterscheiden die sich stark?ein paar erfahrungswerte wäre echt cool.Mein 3ware 9650SE wird recht warm, trotz der ganzen lüfter die im gehäuse hängen! Hat schon mal jemand von euch einen Kühlkörper auf den Proz geklebt, so das sich die oberfläche vergrößert und der gute dann vllt ein bisschen kühler ist? Oder mach ich mir zu viel sorgen, is ja nur die 8 Port variante. is glaub ich der gleiche chip drauf wie auf den anderen der 9650SE-serie auch .. allerdings hat der 12er schon so was drauf kleben wenn ich den bilder im netzt glauben schenken darf… mit dieser frage bin ich im meisterkühlerforum ja gold richtig. 🙂 von kühlung hab ich nämlich mal null ahnung.Vielen Dank für eure antworten 🙂 echt super hier!MfG DrDoom

Re,

DrDoom;456764 said:
Hat mal einer von euch ein RAID 5 mit 8 Platten aus I/O-sicht mit einem RAID 6 aus 8 Platten verglichen? unterscheiden die sich stark?
ein paar erfahrungswerte wäre echt cool.

Nein, leider noch nicht. Die ersten Werte könnte ich mit viel Glück in den nächsten Monaten zur Verfügung stellen. I/O-Werte sind in unserem Sinne auch nicht maßgeblich 😉 … uns geht es um den maximalen Platz bei angemessener Redundanz. Und solange du keinen reinen Datenbank-Server betreibst, brauchst du dir über IOPS keine Gedanken machen … oder meintest du vllt. Lese-/Schreibgeschwindigkeit?

DrDoom;456764 said:
Mein 3ware 9650SE wird recht warm, trotz der ganzen lüfter die im gehäuse hängen! Hat schon mal jemand von euch einen Kühlkörper auf den Proz geklebt, so das sich die oberfläche vergrößert und der gute dann vllt ein bisschen kühler ist?

Nunja, ganz Verrückte haben ihren RAID-Controller auf WaKü umrüsten lassen 😉 …

Leider ist das bei den Dingern mit der Kühlung nicht weit her, die werden alle für Server-Setups gemacht, wo ein ordentlicher Luftstrom herrscht – der reicht dann meistens bequem aus, den kleinen bis winzigen passiven Kühlkörper ausreichend Wärme abzunehmen. Bei allen RAID-Controllern ist es möglich den Kühlkörper abzunehmen, allerdings haben nicht alle Löcher um auch wieder etwas Vernünftiges dranzuschrauben. Schaut doch mal selber das PCB an, ob um den Proz. Befestigungslöcher sind, wenn ja kannst du mal die Diagonale messen und dich dann nach einem anderen umsehen (NB/SB-Kühler gibbed ja für LuKü zum Tauschen) – oder machst eine WaKü drauf (ebenfalls einen passenden NB/SB-Kühler suchen)

Sc0rp

Sodele,
nachdem ich meinen ROCKY wiederbelebt habe (Extra-Fred folgt) und ich dem meinen ersten Hardware-RAID-Controller spendiert habe (Intel SRCS16), ist mir beim Erstellen des DATEN-RAID5 aus meinen vier ‘alten’ 500GB Seagates aufgefallen, das in unserer tollen Aufstellung noch die praktischen Beispiele fehlen:

XFS Filesystem erstellen:
[code]
mkfs.xfs -d su=64k,sw=3 /dev/blah
[/code]
-> evtl. noch zusätzliche Optionen hinzufügen

Eintrag in der fstab
[code]
/dev/blah /mount/point xfs inode64[,nobarrier] 0 0
[/code]
-> evtl. noch zusätzliche Optionen hinzufügen

Ich habe das RAID mittels LVM ‘partitioniert’ … damit ich später erweitern kann.

OT zum Grübeln
Der Controller kann leider nur max. 2TB grosse Blöcke an das BS weitergeben (“verwalten”), davon aber 256 Stück :fresse: – das kann man dann hinter her mit LVM wieder zusammenstückeln 😉

Nun die Grübelfrage: LVM mit Striping (bzw. Chunking) oder nicht?

Sc0rp

Du hast mein volles Beileid und fetten :respekt: 😉

Bei Punkt i) brauchs’de dir keine Sorgen machen … niemand hält dich für ‘bekloppt’ – die meisten WISSEN es 😯

Sc0rp

ps: da nun der Penthatlon vorbei ist, gehts auch bei mir rund. Eigene Hardware, Haus und Garten, Auto … als Lückenfüller zwischen Frau und Kind 😀

drdope;457768 said:
Verdammter Luxusstreß… 😉

That Life 😀

Mercedes SL 320-24V = Winterauto? 😆 richtig kultig wäre der Ur-SL, aber für einen in Bestzustand muß man lange sparen :-#

Hey,

ich dachte I/O bedeutet Input/Output was ich für mich mit Schreb-/Lesegeschwindigkeit übersetzt habe.

Meine Pläne liegen vorerst auf Eis weil 2 der 4 neuen Hitachi Platten nach dem das RAID Build und der Verify fertig waren (was insgesagt etwa 22h dauerte) 7 und 13 Reallocated Sectors verzeichnet haben. Mein Controller hat mir wärend der ganzen Zeit also immer schön mails geschickt. Desshalb hab ich mich entschieden die 2 Platten zu tauschen. Das wird jetzt etwas dauern. Bis dahin wollte ich drdope noch mal nach Erfahrungswerten ausquetschen weil mich das doch interessiert, und ich es selber aber erstmal nicht testen kann!

Ach noch was, beim RAID 6 Build von 8 mal 2 TB hat mein Controller mir eine Stripesize von 256KB angeboten, die ich auch entsprechend eurem Vorschlag beibehalten habe. Könntest du, Sc0rp, auch noch mal schreiben wie du ein mkfs.ext3 anlegen würdest, hab jetzt verschiedene Parameter gefunden -F und -L und noch so zwei drei und ich bin mir nich sicher was ich besser finden soll.

MfG DrDoom

DrDoom;457795 said:
ich dachte I/O bedeutet Input/Output was ich für mich mit Schreb-/Lesegeschwindigkeit übersetzt habe.

I/O bedeutet auch Input/Output, bei RAID-Verbünden wird damit umgangssprachlich die IOPS (Input/Output (Aktionen) pro Sekunde) abgekürzt. Besonders im Hinblick auf Datenbanksysteme mit vielen verteilten Zugriffen ergibt sich hier durch die Wahl des RAID-Levels und dessen Verschachtelung (RAID 1+0 vs. RAID 0+1 z.B.) eine deutliche Verbesserungen. Das betrifft allerdings nur “rotierende” Datenträger, deren native IOPS-Leistung unter aller Würde ist (die schnellste SAS-HD schafft ca. 340 IOPS bei 4ms Zugriffszeit – im Vergleich zu einer popeligen SSD mit 10.000 IOPS mit einer Zugriffszeit von 0,1ms ein echter Witz!)

DrDoom;457795 said:
Ach noch was, beim RAID 6 Build von 8 mal 2 TB hat mein Controller mir eine Stripesize von 256KB angeboten, die ich auch entsprechend eurem Vorschlag beibehalten habe. Könntest du, Sc0rp, auch noch mal schreiben wie du ein mkfs.ext3 anlegen würdest, hab jetzt verschiedene Parameter gefunden -F und -L und noch so zwei drei und ich bin mir nich sicher was ich besser finden soll.

Welchen Partitionierungsansatz möchtest du nehmen?
Du hast jetzt erstmal Schicht 1 erledigt: den “Hardware-Layer” (RAID-Verbund mit Stripe-Size 256k aufgesetzt), nun folgt die zweite Schicht: die Partitionierung.
Da gibt es zweit Möglichkeiten: GPT-Partitionstabelle, oder LVM (LVM2 um genau zu sein). Zweiteres empfehle ich gerne, Ersteres wäre vermutlich unter Windows die bessere Lösung.

Da du EXT3 einsetzen möchtest, gehe ich von einem ordentlichen Betriebssystem für einen stabilen Server aus: Linux ;). Allerdings rate ich dir von EXT3 ab, XFS macht einen wesentlich performanteren Eindruck (siehe mein Eintrag weiter oben)

Meine klare Empfehlung lautet daher: LVM mit XFS 😉 – solltest du doch EXT3 bevorzugen:
[code]
mkfs.ext3 -E stride=64 /dev/blah
[/code]
sollte reichen. “-F” (Force) brauchst du gar nicht und “-L” (Label) kann man vergeben, muss man aber nicht. Stride errechnet sich aus 256k Stripe-Size durch 4k Clustergröße bei EXT3 und ergibt den Block an Daten die auf einen Rutsch geschrieben werden soll(te). Ansonsten brauchst du keine weiteren Schalter!

Sc0rp

Mal wieder ein Fettes Danke für deine schnell Antwort Sc0rp, ich glaub ich muss dir bald mal einen ausgeben 🙂

und da fallen mir gleich weitere fragen ein.
warum überhaupt eine Partitionstablle oder LVM wenn ich eh nur ein Volume habe. Man kann ja auch ohne arbeiten. Hab ich jetzt 2 jahre gemacht .. ohne probleme hab einfach auf sda ein FS draufgeknallt .. anstatt alles zu einer partition zu machen und dann sda1 zu formatieren ..

ich hab mir auch überlegt das das ansich ne gute idee is, ein layer weniger bedeutet ja eine fehlerquelle weniger, sollte sich also im ganzen auch positiv auf die performance auswirken. oder is das totaler quatsch?

Vielen dank 🙂

MfG DrDoom

Re,

DrDoom;457817 said:
Mal wieder ein Fettes Danke für deine schnell Antwort Sc0rp, ich glaub ich muss dir bald mal einen ausgeben 🙂

Dafür bin ich immer zu haben 😉

DrDoom;457817 said:
warum überhaupt eine Partitionstablle oder LVM wenn ich eh nur ein Volume habe. Man kann ja auch ohne arbeiten. Hab ich jetzt 2 jahre gemacht .. ohne probleme hab einfach auf sda ein FS draufgeknallt .. anstatt alles zu einer partition zu machen und dann sda1 zu formatieren ..

Gute Frage, ich hab das noch nie gemacht. Bisher hab ich immer brav partitioniert, vermutlich aus Gewohnheit. Ohne könnte es auch gehen, man spart sich in der Tat eine Schicht – mehr Performance bringt das aber nicht! Weniger Fehler – vielleicht, dann aber nur systemische udn die merzen wir ja mit dem Thread hier aus 😉 … und man kann solche Blockgeräte dann auch nur noch unter Linux betreiben.

Partitionierung hat schon Sinn – ausser beim Spezialfall (genau) einer Partition pro physikalischem Laufwerk, besonders bei modernen RAID-Controllern kann man ja die Verbünde Controllerintern schon aufteilen – es werden dann mehrere “pysikalische” Laufwerke an das Betriebssystem weitergemeldet, womit man wieder die Partionierung einsparen könnte …

@DrDoom: ausprobieren und rückmelden – hier ist der richtige Thread dazu! 😉

Sc0rp

ps: ich werde mal weiter drüber nachdenken, was dann mit AFT und der FS-Struktur passiert, auch im Hinblick auf “resizing”.

Moin Moin,die neuen Platten sind gestern gekommen, es geht also endlich weiter. Hab gerade mal mkfs.ext3 -E stride=64 /dev/sda gemacht. wie du gesagt hast. und dann musste ich feststellen, das er mir eben ausgegeben hatBlockgröße=4096 (log=2)Fragmentgröße=4096 (log=2)nun hab ich doch aber das extra so gemacht damit ich die gleiche blockgröße wie meine stripesize habe .. und die is doch 256KBytehmm??

Tagchen,

DrDoom;458959 said:
Moin Moin,mkfs.ext3 -E stride=64 /dev/sda gemacht. wie du gesagt hast. und dann musste ich feststellen, das er mir eben ausgegeben hatBlockgröße=4096 (log=2)Fragmentgröße=4096 (log=2)nun hab ich doch aber das extra so gemacht damit ich die gleiche blockgröße wie meine stripesize habe .. und die is doch 256KByte

Das hast du falsch verstanden. Abgesehen davon, das due mit EXT3 keine Blockgrössen von 256KiB machen könntest, weisst der Paramter[code]stride=xyz[/code]das Dateisystem darauf hin, das Daten im Raster von stride*blockgrössen (in deinem Fall 64*4KiB=256KiB) organisiert sind. Das bedeutet, das dein Dateisystem Daten im 256KiB-Raster liest und schreibt, also 64 Blöcke als ‘ein Stripe behandelt’. Und das ist auch schon alles, was EXT2/3/4 zu Thema RAID kann.Natürlich kann man die Blockgrösse anpassen (max. 64KiB afaik), aber wie es bei XFS schon steht: “use the defaults”! Sonst bewegt man sich schon im Bereich “spezielles Dateisystem-Tuning”, und das behandeln wir hier nicht ;)Sc0rp

größere Blöcke bringen ja eh kaum vorteile – entscheidend ist ja das die hdd immer gleich einen “schwung” verarbeitet

Alles klar, hab gerade mal geguckt 8KByte Blocksize sind wohl auch noch möglich aber nur:”In Linux, 8 KiB block size is only available on architectures which allow 8 KiB pages, such as Alpha.”was immer das genau heißt?!?!Ferner habe ich folges gefundenExt3 ist langsamer als andere moderne Journaling-Dateisysteme, wie zum Beispiel XFS oder JFS, dafür jedoch relativ robust.Weiterhin überschreibt ext3 bei Löschvorgängen die Block-Pointer der Inodes mit Nullen. Dies erschwert ein Wiederherstellen gelöschter Dateien, erhöht jedoch die Wahrscheinlichkeit, dass die Integrität des Dateisystems nach einem Programmfehler oder Systemausfall ohne Datenverlust wiederhergestellt werden kann. Ein Wiederherstellen der Daten ist mitunter dennoch möglich.Quelle: Wikipediawenn das stimmt find ich ext3 für mich irgendwie geiler den ich hab vorhin ma folgendes gemacht:[CODE]dd bs=1M iflag=direct count=50000 if=/dev/sda of=/dev/null[/CODE]die antwort darauf war überraschend 411MByte/sanschließend hab ich noch [CODE]dd bs=1M oflag=direct count=50000 if=/dev/zero of=/dev/sda[/CODE]ausgeführt, hier hat er mir 394MByte/s ausgespucktfür mein RAID 6 aus 8 mal 2 TB 7200er an einem 9650SE mit Stripesize von 256KByte, keine Partition sondern halt das RAW-device sda mit ext3 mit blockgröße 4KB formatiert, garnicht mal schlecht, wenn das stimmt was bei wikipedia steht, und ext3 langsamer ist als xfs.was habt ihr da eigentlich so für werte?da ich mit meiner konfiguration an alle grenzen gestoßen bin werde ich wohl definitiv auf ext 3 setzen. da ich ja alles mit dm_crypt verschlüssen werde und mein kleiner A64 X2 4200+ eh nur 50-60Mbyte/s verschlüssen kann sollte das schon alles passen.da ich noch mein altes debian lenny mit 2.6.26er kernel am rennen hab weiß ich nich wie ich xfs testen kann? wollt jetzt nich extra neu installieren um xfs zu testen.

Gleich nochemal:
*hab ich ganz vergessen*

drdope;457933 said:
Ab (Gentoo-)Kernel 2.37 läuft der bisherige Areca-Source-Treiber (Stand Mitte 2010) nicht mehr; er kompiliert zwar sauber, aber schmiert beim laden ab…

Der aktuelle (Stand Ende 30.03.11 –> http://www.areca.us/support/s_linux/driver/arcmsr.1.20.0X.15-110330.zip löppt mit 2.37 ohne Probs…
🙂

Gut zu wissen – ich hätte mich vermutlich dabei wieder fast umgebracht 😉 das Ding zu laufen zu bekommen. Naja, aufgrund meiner Tätigkeiten ausserhalb des IT-Breiches (GARTEN, Wohnung, etc.) komme ich grad nur zu “Notreparaturen” an meinen PCs … also liegt auch mal wieder die BiGBOX auf Eis … *dammit*

Sc0rp

Re,

DrDoom;458985 said:
Alles klar, hab gerade mal geguckt 8KByte Blocksize sind wohl auch noch möglich aber nur:
“In Linux, 8 KiB block size is only available on architectures which allow 8 KiB pages, such as Alpha.”
was immer das genau heißt?!?!

So fern ich weiss, kann man ganz normal bis 64KiB Blockgröße gehen mit EXT2/3/4, allerdings ist das relativ suboptimal, da Linux intern mit 4KiB-Pages arbeitet – man könnte dazu auch Chunks sagen – alle Daten werden in 4KiB-Blöcken ‘bearbeitet’.

DrDoom;458985 said:
die antwort darauf war überraschend 411MByte/s

Das liegt im grünen Bereich, rechne mal 411MiB/s durch 8 … macht 50MiB/s pro Festlatte, das ist sehr gut (mit etwas Feinarbeit kommt man durchaus auch auf 60-70MiB/s, aber da muss man schon ordentlich ‘feilen’). Wohlgemerkt beim Schreiben mit doppelter Parität!

Du musst halt wissen was du vornehmlich mit deinem schönen grossen RAID machen möchtest, sofern du hauptsächlich grosse Dateien (Videos, ISOs, Festplatten-Images, etc.) hast sind 256KiB Stripe-Size am Performance trächtigsten. Hast du mehr kleine Dateien (MP3s, Bilder …) dann ist 64KiB Stripe-Size sinnvoller.

DrDoom;458985 said:
was habt ihr da eigentlich so für werte?

Noch keine – Werte sind immer Szenario abhängig und wenige sind aussagekräftig. Und wir konnten uns noch zu keinem einheitlichen
‘Benchmark’ durchringen …

DrDoom;458985 said:
da ich ja alles mit dm_crypt verschlüssen werde und mein kleiner A64 X2 4200+ eh nur 50-60Mbyte/s verschlüssen kann sollte das schon alles passen.

Wie kommst du auf den Wert?

DrDoom;458985 said:
da ich noch mein altes debian lenny mit 2.6.26er kernel am rennen hab weiß ich nich wie ich xfs testen kann? wollt jetzt nich extra neu installieren um xfs zu testen.

Tja, aber darauf läuft es wohl hinaus, denn ich glaube kaum das du nochmal acht Festplatten kaufen möchtest 😉
Aber testen musst du nicht, nimms einfach hin. Dein RAID läuft gut, und wenn das mit dem dm_crypt klappt ist alles in Butter – bis zum nächsten Festplatten-Upgrade, da kannsde dann testen 😉

Sc0rp

was habt ihr da eigentlich so für werte?

Noch keine – Werte sind immer Szenario abhängig und wenige sind aussagekräftig. Und wir konnten uns noch zu keinem einheitlichen
‘Benchmark’ durchringen …

Sicher ist es umstritten, wenn man auf exakte quantitative ergebnisse aus ist. das ist aber eben nur in der realität möglich. ich für meinen teile hätte gerne qualitative werte die ich miteinander vergleichen kann um zu wissen wo ich mich einordnen kann

da ich ja alles mit dm_crypt verschlüssen werde und mein kleiner A64 X2 4200+ eh nur 50-60Mbyte/s verschlüssen kann sollte das schon alles passen.

Wie kommst du auf den Wert?

weil mein RAID 5 aus den ersten 4 Platten auch schon verschlüsselt war, und da hatte ich immer meine 50-60Mbyte/s .. komischer weise nicht bei 100% CPU time .. die cpu hat auf einem core 80%last auf dem anderen max 20% last .. ich werde wohl noch mal durch die dm_crypt config durch müssen um da vllt noch etwas mehr rauszuholen.

najut .. dann bleib ich einfach bei ext3 .. ich wollte halt nur mal erreichen .. das wir hier in diesem thread auch mal ein paar werte zusammen tragen .. mich würde z.B. brennend interessieren wie sich ein ICH10R 5 oder 6 platten RAID 5 hierbei schlägt … bzw. eure Areca so machen ..

MfG

Re,

DrDoom;459068 said:
najut .. dann bleib ich einfach bei ext3 .. ich wollte halt nur mal erreichen .. das wir hier in diesem thread auch mal ein paar werte zusammen tragen .. mich würde z.B. brennend interessieren wie sich ein ICH10R 5 oder 6 platten RAID 5 hierbei schlägt … bzw. eure Areca so machen ..

Okay, drdope wird sicher mal seine Werte posten, und ich auch, sofern ich mal wieder Zeit und Geld habe um meine BiGBOX fertig zu stellen.
Für Adaptec (5805@WaKü) kann ich nur Werte für ein vier HD-RAID5 zur Verfügung stellen, das allerdings mit 4x10k SAS und 4×7.200er Seagates.

Sc0rp

Super, vielen dank drdope

bin atm auf ein paar interessante dinge gestoßen, hab mich in vorbereitung auf die verschlüsselung meines arrays mit dm_crypt/luks/cyptsetup etc auf diese seite gestützt

http://www.andreas-janssen.de/cryptodisk.html

und zwar war ich gerade bei dem punkt “Luks-Partition vorbereiten” und hab
[CODE]dd if=/dev/urandom of=/dev/sda bs=10M[/CODE]
ausgeführt. Nach über 62h hab ich mir gedacht .. nanu .. meine schreibwerte von oben genannten 400MByte/s .. da stimmt was nich

ich hab dd zu einer Zwischenstand ausgabe überredet
[CODE]root@localhost # kill -USR1 DD-PID[/CODE]
die anwort von dd war niederschmetternd
1,3TB kopiert, 224734s, 5,6MByte/s

ein wenig nachforschen .. urandom ist schuld, es geht einfach nich viel schneller zumindest nich mit handelsüblichen cpu’s .. ein i5 in meiner nähe kommt auf 8,2MByte/s und mein kleiner a64 x2 4200+ eben nur auf 5,6 MByte/s .. nunja .. da ich den rechner keine 30 tage durchnudel lassen will zumal meine daten atm auf geborten platten ohne sicherheit rumliegen .. wollte ich das ganze nich unnötig in die länge ziehen und habe mich nach etwas recherche und beratung mit einem freund dafür entschieden diesen punkt nicht weiter zu verfolgen.

ferner wollte ich eine weiter sache ansprechen auf die ich gestoßen bin.
mein debian squeeze wird jetzt abgeschafft und ich werde auf das neue ubuntu natty narwhal setzen weil dieses den 2.6.38er kernel verwendet und der dm_crypt dort jetzt mit mulicore support ausgestattet wurde .. also endlich kann ich das system mal auslasten 🙂

so das war’s erstmal .. ich werde euch weiter auf dem laufenden halten ..

mfg und gn8

Hi,

DrDoom;459940 said:
[CODE]dd if=/dev/urandom of=/dev/sda bs=10M[/CODE]
ausgeführt. Nach über 62h hab ich mir gedacht .. nanu .. meine schreibwerte von oben genannten 400MByte/s .. da stimmt was nich

ich hab dd zu einer Zwischenstand ausgabe überredet
[CODE]root@localhost # kill -USR1 DD-PID[/CODE]
die anwort von dd war niederschmetternd
1,3TB kopiert, 224734s, 5,6MByte/s

ein wenig nachforschen .. urandom ist schuld, es geht einfach nich viel schneller zumindest nich mit handelsüblichen cpu’s

Japp, das urandom solch ein Ressourcenverschwender ist, ist hinlänglich bekannt. Man kann aber auch “/dev/random” nehmen – zum Befüllen der Platte mit “zusammengewürfelten Bytes” reicht das Dicke aus! Müll bleibt Müll, auch wenn der eine ‘noch zufälliger’ sein sollte ;). Es geht ja nur darum die Platte mit Zufallszahlen zu beflastern, damit man hinterher keinerlei Rückschlüsse auf den Container ziehen kann …

Sc0rp

ps: selbst mit Multicore-Support wird das mit urandom ein Geduldsspiel, wenn ein Kern 5,6MiB/s bringt, wie viele brauchst du dann wohl für 400MiB/s? 😯

Sc0rp;459953 said:
Hi,
Japp, das urandom solch ein Ressourcenverschwender ist, ist hinlänglich bekannt. Man kann aber auch “/dev/random” nehmen – zum Befüllen der Platte mit “zusammengewürfelten Bytes” reicht das Dicke aus! Müll bleibt Müll, auch wenn der eine ‘noch zufälliger’ sein sollte ;). Es geht ja nur darum die Platte mit Zufallszahlen zu beflastern, damit man hinterher keinerlei Rückschlüsse auf den Container ziehen kann …

Sc0rp

ps: selbst mit Multicore-Support wird das mit urandom ein Geduldsspiel, wenn ein Kern 5,6MiB/s bringt, wie viele brauchst du dann wohl für 400MiB/s? 😯

sorry .. aber ich hab das eben mal getestet .. und /dev/random is viel viel viel langsamer als /dev/urandom so um die 0,1KByte/s .. und das deckt sich auch mit dem was in wikipedia zu diesem thema steht .. oder hab ich was übersehen? gibt es vllt noch eine andere möglichkeit?

mfg

Oha, das habe ich nicht gewusst
–> http://de.wikipedia.org/wiki//dev/random

DrDoom;459959 said:
sorry .. aber ich hab das eben mal getestet .. und /dev/random is viel viel viel langsamer als /dev/urandom so um die 0,1KByte/s .. und das deckt sich auch mit dem was in wikipedia zu diesem thema steht .. oder hab ich was übersehen? gibt es vllt noch eine andere möglichkeit?

Ich hab anscheinend noch nie den Entropiepool ausgereizt … bei mir lief das immer durch, klar das bei einem “grossen” Datenträger der Pool relativ schnell erschöpft ist …

Kein Wunder, auf meiner Bastelkiste:
[CODE]
sc0rp@DSM:~$ cat /proc/sys/kernel/random/poolsize
4096
sc0rp@DSM:~$ cat /proc/sys/kernel/random/entropy_avail
138
sc0rp@DSM:~$ uname -a
Linux DSM 2.6.32-32-generic #62-Ubuntu SMP Wed Apr 20 21:54:21 UTC 2011 i686 GNU/Linux
sc0rp@DSM:~$ uptime
19:18:15 up 5 days, 22:19, 2 users, load average: 0.00, 0.00, 0.00
sc0rp@DSM:~$
[/code]
Anscheinend braucht man ziemlich viele Gerätetreiber die Rauschen aufnehmen können, um den Entropiepool voll zu machen … 138/4096 sind nach fünf Tagen kein berauschendes Ergebniss … 🙄

Eine andere Möglichkeit kenn ich nicht, sorry.

Sc0rp

heute sollte es soweit sein, ein paket mit am3 board phenom x2 560 und 4 GB DDR3 ram ersetzen den 939er a64 x2 4200+ mit 3 GB DDR ram weil dem bei den letzten umbaumaßnahmen die onboard graka abgeraucht ist. ich vermute einen bösen wackelkontakt am vga port .. naja .. der x2 lässt sich mit etwas glück zu einem x4 via ACC freischalten .. mal gucken .. wenn nich auch nich weiter schlimm ..

ich bin auf einen misteriösen error gestoßen, als ich natty installiert hatte, den noch keiner so recht gelöst hat ..

[CODE]3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85[/CODE]

is schon komisch, weil unter debian squeeze das ich installiert hab um den fehler zu verifizieren weil im inet steht das da wohl platten oder sowas kaputt sind .. musste ich feststellen das dieser fehler bei debian nicht auftritt, desswegen leigt die vermutung für mich nahe das es sich um ein natty btw. 2.6.38er problem handelt ..

jetzt hatte ich überlegt wie drdope auf gentoo umzusteigen und mal zu gucken wie sich der 2.6.38er dort schlägt, aber ich befürchte das ich nicht genug ahnung von gentoo hab als dass ich das so zum laufen bringen könnte, das es für mich passt. mit debian hab ich jahre lange erfahrung und die community is auch verdammt groß ..

bin gespannt ob der neue untersatz eine nennenswerte durchsatzsteigerung mit sich bringt.

mfg

Vielen Dank für die schnellen Antworten!

Sc0rp;461097 said:
Ich habe mal nach dem “Invalid command opcode” gegoogelt, und gleich der erste Hit deckte sich mit meiner Vermutung: da werden SMART-Daten von einem LOGISCHEN statt einem PHYSIKALISCHEN Laufwerk angefordert, wie auch immer. Ein RAID-Device kann das natürlich nicht liefern – der Controller müsste sich für eine Festplatte entscheiden. “Invalid command” hat auch niix mit Devices bzw. Festplatten (-fehlern) zu tun, “opcode” könnte sich zwar schon auf eine bestimmte (S) ATA-Funktion beziehen, aber sowas fängt der Controller normalerweise ab.
Festplattenfehler werden mit generell mit “Device-Error” gekennzeichnet.

jo das hatte ich auch gefunden, konnte dies jedoch als fehlerquelle ausschließen, weil mein natty-server garkein smartd oder smartmontools am laufen hatte (konne auch kein anderes tool ausmachen?!?!?!?) also konnte dieser demon dieses problem nicht verursachen.

der erste google hit ist Thomas Kern

kernel: 3w-9xxx: scsi2: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x4D
Diese Fehlermeldung taucht auf wenn SMART Werte anstatt von einem physikalischen, von einem logischen Laufwerk angefordert werden. Überprüfen Sie die Einstellungen in /etc/smartd.conf

0x4D ist leider nicht 0x85 ich find aber echt schade das 3ware bzw. LSI dazu nichts sagen kann!?!?

Ich hab die Vermutung das es sich um ein Treiberproblem handelt, dann würde so eine ausgabe wohl auch kommen. und ja .. wenn ich nich weiß was das ausslöst, dann kann ich auch nicht einschätzen ob das schlimm oder weniger schlimm ist .. ich würde mich nur nicht wohl fühlen wenn ich weiß das sich mein system mit fehlern rumquält die nicht not tun.

@drdope:
da gebe ich dir 100% recht! und ich hätte auch wirklich gerne ein Intelsystem gekauft, aber die Preise sind einfach zu hoch für mich als studenten, so viel kann ich garnich arbeiten nebenbei um mir das leisten zu können. der preiswerteste Intel mit AES kostet 140 Euro .. ich hab jetzt für 180 Euro Board CPU und RAM bekommen. Wichtig war mir, das ich 2 PCIexp16 Ports hab (also einmal 16 einmal elektrisch 8) damit ich 2 Raidcontroller rein bekomme. Das ist bei Intel so ein Problem den die H67 haben so wenig exp. Lanes .. das erste board das meine anforderungen erfüllt kostet 123 Euro und dann noch RAM dann wären wir bei 293 Euro. Da es sich um eine Ungeplante anschaffung handelte .. musste ich eben kompromisse eingehen. Mein jetzt bestelltes system sollte auf 100-120Mbyte/s kommen und würde damit die Gbit/s netzwerkkarte auslasten. und mehr input hab ich quasi eh nich. also brauch ich die traumhafte AES verschlüsselungsgeschwindigkeit von 2-3GByte/s nicht.

zu gentoo, ich finde automatismen sehr nützlich und hilfreich. Ich bin jetzt wirklich nicht der linux ***** das ich alles selber machen kann. bei debian stable weiß ich was ich hab .. das is dann auch stable bis zum abwinken. ich hab schon lange genug gebraucht mit debian klar zu kommen. da ich nicht so viel zeit hab mich richtig in gentoo reinzuarbeiten .. und ubuntu der kleine hässlige und unzuverlässige bruder von debian ist .. sind meine möglichkeiten doch ziehmlich eingeschränkt.

mfg

Re,

DrDoom;461060 said:
ich bin auf einen misteriösen error gestoßen, als ich natty installiert hatte, den noch keiner so recht gelöst hat ..

[CODE]3w-9xxx: scsi0: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85[/CODE]

Ich habe mal nach dem “Invalid command opcode” gegoogelt, und gleich der erste Hit deckte sich mit meiner Vermutung: da werden SMART-Daten von einem LOGISCHEN statt einem PHYSIKALISCHEN Laufwerk angefordert, wie auch immer. Ein RAID-Device kann das natürlich nicht liefern – der Controller müsste sich für eine Festplatte entscheiden. “Invalid command” hat auch niix mit Devices bzw. Festplatten (-fehlern) zu tun, “opcode” könnte sich zwar schon auf eine bestimmte (S) ATA-Funktion beziehen, aber sowas fängt der Controller normalerweise ab.
Festplattenfehler werden mit generell mit “Device-Error” gekennzeichnet.

Also: keine Panik. Versuchen den Störenfried ausfindig zu machen und nach zu regeln, oder einfach ignorieren 😉

Gentoo hab ich mir auch schwieriger vorgestellt, bin ja durch drdope dazu gekommen. Seitdem setze ich meine dedizierten Server nur noch damit auf (und das mit dem Minimal-ISO inkl. selbst angepasstem Kernel!). Ich finde das nicht schwieriger als Ubuntu, und es ist genauso gut dokumentiert.

Sc0rp

danke @ drdope,

den hatte ich auch gefunden, und dann wollte ich die einträge in der smartd.conf einfügen und musste feststellen, das die nicht existiert, bzw. smartmontools nicht installiert ist. wie kann also der treiber meines raid controllers, einen fehler ausspucken der von einem programm verursacht wird, das nicht vorhanden ist? also wird dieser fehler anders verursacht. blos wie ist die frage. weiß er welches programm die aufgabe von smartmontools bei natty übernimmt? weil bei meiner standard natty install wurde smartmontools nicht installiert, und auf der suche nach dem hier verwendeten programm bin ich nicht weiter gekommen. ich hab mir überlegt, das smart jetzt wohl seit dem 2.6.38er kernel intern abgearbeitet wird, und das dieser prozess jetzt meinen treiber dazu veranlasst diesen fehler auszuspucken .. is aber nur eine theorie von mir 🙂

mfg

OT1
Es müssen ja nich die “smartmontools” installiert sein, es reicht eine Bibliothek (*.lib / Library / DLL) davon … welches Proggi die nun mitbringt bzw. nutzt bekommt man mit ganz schön Aufwand schon raus, aber besser wäre es vermutlich einfach die smartmontools zu installieren und dann die vorhandene *.cfg zu editieren 😉

OT2
Gentoo ist wirklich sehr schlank und kann optimalst auf deine Hardware angepasst werden -> null Ressourcenverschwendung. Das waren die Hauptgründe für mich von Ubuntu zu Gentoo zu wechseln – bei Ubuntu ging mir z.B. der AVAHI-Mist ganz schön auf die Nerven …

OT3
AES-NI ist schon schön (sofern man es im Kernel aktiviert), das soll ja sämtliche AES-Berechnungen ordentlich beschleunigen:
-> Truecrypt soll damit mehr als sechsmal so schnell werden 😯 !

Sc0rp

Sc0rp;461137 said:
-> Truecrypt soll damit mehr als sechsmal so schnell werden 😯 !

Das ist schon ordentlich :d: Interessant wäre mal, wie sich da sauf den verbrauch auswirkt. Ist die CPU dann zu 100% ausgelastet?

Bin mal gespannt, wie sich da mein i5-650 schlägt

nabend @ all

@drdope
hab eben dein howto verwendet
“HowTo: Wie man ein Raidarray korrekt aligned; partitioniert; mit XFS formatiert und optimal mounted”

ich musste noch
[CODE]mklabel gpt[/CODE]
machen damit die mkpart routine anläuft .. vllt schreibst du das noch dazu?

mein neues board is da .. lüppt alles soweit ..leider ließ sich der x2 nich zu einem x4 machen, verfolge das aber auch nicht weiter .. hab ein bisschen getestet mit den weiter oben aufgeführten werten komm ich jetzt auf 500Mbyte/s beim Schreiben und 480 Mbyte/s beim lesen. Is also irgendwie noch ma ne ecke Schneller geworden. Mein neuer Proz schafft bei urandom 9MByte/s .. was ich schon cool finde .. der i5 661 vom kumpel schafft da nur 8,2Mbyte/s

ich hab etwa einen halben tag damit zugebracht herauszufinden ob gentoo nich doch was für mich ist .. und nachdem ich herausgefunden hab das es keine installationsroutine gibt .. war ich so geschockt .. das ich das über eine live version machen soll .. das ich mir gedacht hab, wenn man sich da nich genug auskennt, dann brauch man garnich anfangen. dann macht man schon bei der installation so viel falsch das das system am ende garnich richtig laufen kann. ich frag mich echt wie ihr das hinbekommen habt .. die hürde das system zum laufen zu bekommen ist so fies hoch .. das macht einfach keinen spass.

Ich ziehe meinen Hut vor allen gentoo-usern!!

MfG

Re,
gibt es nicht schon einen Gentoo-Thread? Dann bitte dorthin verschieben 😉

drdope;461413 said:
Einfach nicht abschrecken lassen, die Installation ist im Handbuch sehr gut erklärt. Als ich mit Gentoo angefangen habe, hatte ich auch nur ca. 6 Monate Linux-Erfahrung (3 Monate Suse und 3 Monate Ubuntu 5.04 iirc).
Das wichtigste ist, daß man nicht stumpf abtippt bzw. c&p’ed sondern nachvollzieht/versteht, was man da eigentlich grade macht.

Genau: schön das deutsche (!) Handbuch “daneben legen” und dann Schritt für Schritt das Linux-System aufbauen, das dauert das erste Mal etwas länger, aber dafür ist der Lerneffekt deutlich ausgeprägter! Ich finde das nicht schwieriger als die ersten RedHat-Releases die mir unter die Finger kamen … und hinterher erhält man ein wirklich schlankes System, das bestens auf die vorhandene Hardware zugeschnitten ist und absolut Ballastfrei arbeitet – mal abgesehen vom Lerneffekt.

Sc0rp

ps: Gentoo setze ich (im Moment) nur für meine Server ein, Desktops & Laptops laufen unter Ubuntu 10.01 LTS. Demnächst werde ich auch mal die Genkernel-Variante auf einem Desktop versuchen …

littledevil;461208 said:
Das ist schon ordentlich :d: Interessant wäre mal, wie sich da sauf den verbrauch auswirkt. Ist die CPU dann zu 100% ausgelastet?

Bei Interesse könnte ich Verbrauchsmessungen mit Truecrypt bei aktiviertem AES-NI mit nem 661er unter Linux Mint machen…

Hi chris,

chris221177;462012 said:

littledevil;461208 said:
Das ist schon ordentlich :d: Interessant wäre mal, wie sich da sauf den verbrauch auswirkt. Ist die CPU dann zu 100% ausgelastet?

Bei Interesse könnte ich Verbrauchsmessungen mit Truecrypt bei aktiviertem AES-NI mit nem 661er unter Linux Mint machen…

Jupp, das wäre schön. Wir suchen ja unbedingt “Real-World-Benchmarks”, und AES gehört m.E. auf jeden Fall dazu!

Dann kannst du auch gleich die Frage von littledevil beantworten 😉

Danke im Voraus!
Sc0rp

Sc0rp;462018 said:
Jupp, das wäre schön. Wir suchen ja unbedingt “Real-World-Benchmarks”, und AES gehört m.E. auf jeden Fall dazu!

Dann kannst du auch gleich die Frage von littledevil beantworten 😉

Danke im Voraus!
Sc0rp

Sehr gerne, wird aber erst am WE etwas, vorher komm ich nicht nach Haus…

Re,

chris221177;462024 said:
Sehr gerne, wird aber erst am WE etwas, vorher komm ich nicht nach Haus…

Kein Stress … 😉

Schau bitte vorher mal hier nach:
–> http://wiki.debianforum.de/BenchmarkFestplattenverschl%C3%BCsselung (beinhaltet auch den Aufbau des Tests!)
und hier:
–> http://www.robo47.net/blog/198-Intel-AES-NI-dmcrypt-benchmark-with-i7-620M-on-Debian-Squeeze
–> http://www.robo47.net/blog/200-Truecrypt-7.0-Linux-AES-NI-Benchmark-with-i7-620M-on-Dell-Latitude-E6510

evtl. kannst du ja diese Ergebnisse revidieren!

Sc0rp

EDIT: @drdope – den ersten Link können wir ins Thema “Real-World-Benchmarking” übernehmen, wie auch die Posts von DrDoom … und deine Werte natürlich zu Erst 😉

Sc0rp;462048 said:
Schau bitte vorher mal hier nach:
–> http://wiki.debianforum.de/BenchmarkFestplattenverschl%C3%BCsselung (beinhaltet auch den Aufbau des Tests!)
und hier:
–> http://www.robo47.net/blog/198-Intel-AES-NI-dmcrypt-benchmark-with-i7-620M-on-Debian-Squeeze
–> http://www.robo47.net/blog/200-Truecrypt-7.0-Linux-AES-NI-Benchmark-with-i7-620M-on-Dell-Latitude-E6510

evtl. kannst du ja diese Ergebnisse revidieren!

Wird gemacht…

Bin nun doch zu einem halben freien Tag gekommen und hab diesen für ein paar Benchmarks auf dem Mint-Rechner genutzt.
Zuerst zum System:
CPU: Intel Core I5-661
MB: Intel DH57JG
Systemfestplatte: 2,5” Toshiba MK2035GSS 200GB
Netzteil: Bequiet PurePower 300Watt

Für die Benchmarks wurde eine etwas ältere Seagate Barracuda 7200.9 160GB verwendet. Die liegt bei mir noch rum, war damals die erste 160GB mit einem Platter.

Betriebssystem ist Linux Mint 10, eine 32bit Version
Kernel: 2.6.35-24-generic-phc ( Der Tickless PHC – Kernel zum Undervolten der CPU)
Außer dem Undervolting der CPU wurden keine Optimierungen in Bezug aufs Stromsparen vorgenommen.
Truecrypt wurde in der Version 7.0a installiert.

Ich hab mal die Screenshots mit und ohne AES-NI angehängt. Diese Benchmarks laufen komplett im RAM. Ich hoffe, ich bin nicht zu blöd, um die Grafiken zu verlinken…
http://christiansteinle.dyndns.org/truecrypt_w_aesni.png
http://christiansteinle.dyndns.org/truecrypt_wo_aesni.png

Danach habe ich einmal einen 50GB Container mit bzw. ohne AES-NI erstellt. Die Ergebnisse:
Mit AES 69 MB/s
Last: 30% auf allen 4 virtuellen Kernen im Durchschnitt (HT aktiviert)
Verbrauch: 49,7 Watt

ohne AES: 54 MB/s
Last: 75%
Verbauch: 52,3 Watt

Sonstige Verbrauchswerte des Systems:
Idle (Tastatur, Maus, Monitor, LAN, beide HDDs): 32 Watt
Systemüberwachung an: 35 Watt
Truecrypt Benchmark: 49 Watt (100% CPU Last auf allen 4 virtuellen Kernen)
CPUburn (4x burnBX): 55 Watt

Die von Sc0rp verlinkten Debian Tests konnte ich so noch nicht durchführen, werde ich aber bei Gelegenheit nachholen.
Ich hoffe, dass ich dennoch etwas hilfreiches Beitragen konnte.

Beim dem von Sc0rp verlinkten Benchmark
http://wiki.debianforum.de/BenchmarkFestplattenverschl%C3%BCsselung
scheint bei mir etwas nicht zu funktionieren. ich bekomme als Ergebnis maximal 37 MB/s raus. Was da nicht hinhaut kann ich im Moment nicht genau sagen, die CPU – Last liegt im Schnitt bei rund 35%?!:-k

Mein 661 sollte ja mit dem 660er gleich auf liegen. Die Teile unterscheiden sich ja lediglich in der integrierten Grafik…

Hey Leute,ich hab Fertig, Umbau abgeschlossen! Meine Platten sind jetzt zu 50% voll 🙂 Beim raufschieben hab ich mit 70-80MByte/s geschrieben. Zu testzwecken hab ich dann mal über meine Gbit Karte daten vom Array gelesen und habe dabei Spitzenwerte von 110Mbyte/s erreicht. Über samba is das schon so ziehmlich das limit von allem. Werde wenn ich mal lust und Zeit habe ein Bonding austesten und dann mal gucken wieviel der Proz dorch 2 Gbit karten schiebt (eine Onboard eine PCI) den Jetzt hatte ich auch nur 50-80% CPU use.MfG@Chriss: irgendwas kann da bei dir nich Stimmen. Mein Kumpel Schafft mit seinem 661er wesentlich mehr. Wenn er einen Container mit Aktiviertem AES schreibt, is da die Platte das Limit (rund 100MByte/s) und nicht die CPU. den Benchmark im RAM macht er mit mehr als 1 GByte/s

DrDoom;462207 said:
@Chriss: irgendwas kann da bei dir nich Stimmen. Mein Kumpel Schafft mit seinem 661er wesentlich mehr. Wenn er einen Container mit Aktiviertem AES schreibt, is da die Platte das Limit (rund 100MByte/s) und nicht die CPU. den Benchmark im RAM macht er mit mehr als 1 GByte/s

Ja, da bin ich mir genauso sicher. Ich müsste bei der ganzen Geschichte evtl. mal die Taktraten im Auge behalten. Bei einer schlechten Umsetzung der Anpassung der CPU Frequenzen, ist es denkbar, dass bei einer Auslastung von 30% aller Kerne die Frequenz nicht angehoben wird…
Ansonsten bin ich mir natürlich auch nicht sicher, in wie fern Truecrypt auf Mint optimiert ist. Ein weiteres Problem könnte auch sein, dass bei mir kein 64bit Kernel läuft…
Bei Gelegenheit werde ich noch mehr Tests machen. Was aber hier allein aufgrund der CPU – Last klar wird, dass bei aktiviertem AES definitiv die Platte zum Flaschenhals wird, und nicht die Verschlüsselung.
Leider ist mir an meinem Arbeits-PC heute ne Platte abgeraucht. War Gottseidank ein RAID5 und kann den aktuellsten Stand noch sichern. Hat jetzt erst mal Priorität. Sobald ich etwas Luft hab, meld ich mich mit weiteren Testergebnissen zurück…

Re,

DrDoom;462207 said:
Hey Leute,
ich hab Fertig, Umbau abgeschlossen! Meine Platten sind jetzt zu 50% voll 🙂

Grats!

DrDoom;462207 said:
Beim raufschieben hab ich mit 70-80MByte/s geschrieben. Zu testzwecken hab ich dann mal über meine Gbit Karte daten vom Array gelesen und habe dabei Spitzenwerte von 110Mbyte/s erreicht.

Von wo aus hast du geschrieben? Bitte QUELLE und ZIEL plus WEG beschreiben 😉 – aber 110MiB/s … das sind ja 880MBit/s – absolut Spitze über GigabitEthernet!

DrDoom;462207 said:
Über samba is das schon so ziehmlich das limit von allem.

Sagt wer oder was? Sieht ehr nach einem Limit des Netzwerkes aus, bzw. Limit des “Gebers”.

DrDoom;462207 said:
Werde wenn ich mal lust und Zeit habe ein Bonding austesten und dann mal gucken wieviel der Proz dorch 2 Gbit karten schiebt (eine Onboard eine PCI) den Jetzt hatte ich auch nur 50-80% CPU use.

Du solltest erstmal den Durchsatz via FTP testen, ich bekomme damit von einem Single-Host (Desktop-Rechner mit einer Festplatte) fast doppelt so hohe Werte wie bei CIFS (Samba = 30-35MiB/s, FTP = 55-60MiB/s).

GigabitEthernet über PCI32 (@33MHz) ist btw. auch ein Thema für sich – nicht wundern wenn man darüber gerade mal 500MBit/s bekommt ;).

Leider wird meine BiGBOX irgendwie nicht richtig fertig … sonst könnte ich mal RAID6@Server1 -> 2xGigabitEthernet (Kupfer) “bonded” -> RAID6@Server2 benchen, und auch diverse AES-Messungen machen. 🙁

Sc0rp

Hallöchen,sorry für meine unpräzisen angaben Sc0rp :)hab jetzt noch ein bisschen getestet .. weil ich mir erstmal nicht den Stress mit dem Bonding machen wollte hab ich noch ein bisschen mit dd rumgespieltmit[CODE]dd bs=10M count=500 if=/dev/zero of=/mnt/daten/123[/CODE]habe ich eine 5,2 GB große datei names 123 die voll mit nullen ist mit 116MByte/s erstellt.mit[CODE]dd if=/mnt/daten/123 of=/dev/null[/CODE]habe ich diese datei mit 159MByte/s in den Papierkorb kopiert.dann habe ich mir gedacht machst du die datei ma ein bisschen größer[CODE]dd bs=10M count=5000 if=/dev/zero of=/mnt/daten/1234[/CODE]habe ich eine 52GB große datei namens 1234 die voll mit nullen ist mit 112Mbyte/s erstelltmit[CODE]dd if=/mnt/daten/1234 of=/dev/null[/CODE]habe ich diese datei mit 158MByte/s in den Papierkorb kopiert.so dann noch ne 1GB datei erstellt mit 130Mbyte/s und mit 1,2GByte/s gelesenund zu guter letzt ne 524MB datei mit 612MByte/s erstellt und mit 1,2 GByte/s gelesendie CPU last bei den kleinen datein war kaum realisierbar weil es einfach zu schnell ging. Bei den Großen hatte ich auf einem Core immer um die 90-100% CPU use .. die cores haben sich dann vermutlich aus Temperaturgründen abgewechselt.zu meinen nic’s .. hab ne onboard Realtek r8169 und ne PCI32Bit Intel GT1000ich kann also zusammenfassen .. mein system is rattenschnell. so schnell kann ich garnich drauf schreiben bzw. von lesen .. weil ich sonst kaum so ein performantes system habe .. ich ärger mich ein bisschen das ich genau das nich auch mit meinem A64 X2 4200+ mit 3 GB DDR1 RAM mal gemacht habe .. aber das zu testen wäre mir jetzt wirklich zu aufwendig .. ich würde mich freuen mal von anderen leuten ein paar werte zu gesicht zu bekommen :)MfG DrDoom

Moin Leute,hab jetzt mal mein Strommessgerät zwischen server und steckdose gehängt und ich muss zugeben das ich etwas überrascht war.Ich hab mir ja das gleiche NT wie drdope geholt .. weil mir das HX750 von Corsair von den daten und eigenschaften her gut gefallen hat .. aber wenn der PC aus ist, zieht das teil 30Watt. Mein Macmini zeiht 40Watt im Idle wenn er an ist!wenn ich den kleinen Hochfahre is er bei Sportlichen 164 Watt im idle (C’n’Q und C1E an) beim Schreiben auf das Array bei 182 Watt. Ich werde mir wohl mal zeit nehmen müssen und gucken wie ich den Proz untervolten kann .. und vllt noch ein paar andere stromspar tools anwerfen. leider hab ich da mal wieder null peilung von. Ich weiß unter gnome und wenn man debian auf einem notebook installiert macht er das alles automatisch .. jetzt hier bei meiner server install hat er garnichts von all dem dabei .. was auch nich unbedingt verwunderlich ist da ein server ja kein stromsparen soll .. sonder das rechenzentrum heizen soll :)MfG DrDoom

Warum sollte man eigentlich die stripes nicht unter 64kByte setzen? Diese und noch größere Streifen führen doch bei kleinen Dateien dazu, daß der Raid-Vorteil der Geschwindigkeit bei Dateien <64kByte verloren geht, sprich: am Lese- oder Schreibvorgang ist dann doch nur eine Platte des Verbunds beteiligt.In einer typischen Datenbank mit zigtausend Dateien ist aber oft ein großer Anteil der Daten deutlich unter 64kByte. Wäre in so einer Anwendung 32kByte-Streifen oder sogar 16kByte nicht die bessere Wahl?

Das Meßgerät wird nix taugen. Welches ist es denn?

Hmm .. ich hab bisher keinen grund zu der annahme gehabt das das teil so schief liegen könnte. hinzu kommt .. wie viel kann so ein teil schon schief gehen .. die müssen doch alle nach dem gleichen prinzip funktionierenich hab ein Olympia EKM2000 .. und bei meinem macmini early 2009 stand das er 40 Watt verbraucht .. und mein messgerät sagt das auch .. mein 24″ moni soll laut datenblatt auch 120Watt verbrauchen .. und genau das zeigt er mir da auch an .. also wie gesagt … hatte bisher keinen grund anzunehmen .. das was mit dem teil nicht stimmt.mfg

Re,

thethe;463018 said:
Warum sollte man eigentlich die stripes nicht unter 64kByte setzen? Diese und noch größere Streifen führen doch bei kleinen Dateien dazu, daß der Raid-Vorteil der Geschwindigkeit bei Dateien <64kByte verloren geht, sprich: am Lese- oder Schreibvorgang ist dann doch nur eine Platte des Verbunds beteiligt.

Im Prinzip ist das richtig, wenn man den Read-Ahead und den zum Teil sehr grossen Raid-Controller-Cache ausser acht lässt erst recht ;).

thethe;463018 said:
In einer typischen Datenbank mit zigtausend Dateien ist aber oft ein großer Anteil der Daten deutlich unter 64kByte. Wäre in so einer Anwendung 32kByte-Streifen oder sogar 16kByte nicht die bessere Wahl?

Erstens kommt es auf die Datenbank an ob sie aus tausenden Dateien besteht, oder nur aus einer – alle haben aber eins gemeinsam: die schnellen und verteilten IOPS (Lese-/Schreiboperationen pro Sekunde). Dafür nutzt man natürlich kleinere Stripsizes, aber auf jeden Fall (und vor allem) einen anderen RAID-Level (meistens Kombinationen aus 0 und 1 in Verbindung mit hochdrehenden Platten (max. 340 IOPS), bzw. jetzt SSDs mit hohem IOPS-Wert (>50.000 IOPS)).

Sc0rp

Dein Olympia sieht wie mein meßgerät von Aldi aus. Bis 20W kannst Du die Werte vergessen.Bei max mini dachte ich an das sparsame modell. Ist der early von mit Power-PC?

@littledevilMein MacMini early 2009 hat einen Intel C2D mit 2x2GHz 4GB RAM und ne 500er Platte .. ich find die 40 Watt schon garnich schlecht .. hat ja auch den ION GF9400 mit druff .. der wird schon etwas ziehen .. naja .. und mein Olympia is aus’m netto 🙂 aber gut das du das sagst .. blos versteh ich nich ganz wieso das so is?!?!

Betriebst Du den mini @windows?

ok,d as erklärt den hohen verbrauch – aber genug OT

Ja .. das tue ich, macOS ist imho eine qual ..

Moin,

ist es eigentlich besser eine Partition auf dem Raid anzulegen?
Denn momentan habe ich den kompletten Raid mit einem Dateisystem belegt, dadurch funktioniert das Online Resizing besser. Da man nicht erst dei Partitionstablle löschen muss und dann wider anlegen…..
Momentane Fdisk…
[CODE]Platte /dev/sda: 6999.9 GByte, 6999924277248 Byte
255 Köpfe, 63 Sektoren/Spur, 851025 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9d251681

Festplatte /dev/sda enthält keine gültige Partitionstabelle
[/CODE]

Ist als ext3 formatiert.

Nun habe ich weitere HDDs (5x2TB) womit ich nun einen 2. Raid 5 aufsetzen möchte, deshalb die Frage wie es am Besten ist.

Controller 3ware 9690 mit Chembro 24 Port Extender Karte

Gruss
next-creature

Kannst ja einen hackintosh draus machen. Das neue Amcbook Air ist aber sher elcker und hat auch ordentlich power in der “großen” variante

Ich teste gerade 8 Platten im Raid6 am LSI 9260-8i. Kann man irgendwie erklären, warum ich deutlich schneller schreiben als lesen kann? Ich hab jetzt grad nur einige tests mit bonnie++ und dd (rund 16GB geschrieben/gelesen) gemacht und komme auf 670MB/s schreibend und 450MB/s lesend (sequentiell natürlich). Find ich irgendwie komisch. Im Raid5 erhalte ich die gleichen Daten. Cache ist sowohl auf dem Controller als auch auf den Platten eingeschaltet. Write policy ist write back.

Hier nochmal einige realitätsnähere Testergebnisse. Da ich leider keine zwei Raids habe, kann ich nur alle Dateien mittels dd in /dev/null lesen um die Geschwindigkeit zu testen. Dateisystem ist übrigens xfs mit “-d su=256k,sw=6” erstellt. Mit ext3 hatte ich ähnliche Werte lesend wie bei xfs, aber schreibend war deutlich geringer. ext4 hat das Problem beim schreiben gelöst, das möchte ich aber nicht einsetzen.Für die Tests habe habe ich drei Verzeichnisse angelegt:groß – 97,8GB Dateien 8-10GB großmittel – 44,8GB 3-5MB pro Dateiklein – 60.000 50kB kleine Dateien (3GB)Stripe size: 64kgroß: 331,4 Sekunden ~= 302 MB/smittel: 385,6 Sekunden ~= 119MB/sklein: 140,4 Sekunden ~= 21,8 MB/sStripe size: 256kgroß: 212,1 Sekunden ~= 472 MB/smittel: 323,4 Sekunden ~= 142 MB/sklein: 133,6 Sekunden ~= 23 MB/sIch tendiere also eindeutig zu 256k, denn Dateien weit unter 50kB, wo das Raid dann evtl. irgendwann langsamer wird, habe ich nicht in einer Anzahl ab der es relevant wird.bonnie++ mit 256k stripe size:[code]Version 1.96 ——Sequential Output—— –Sequential Input- –Random-Concurrency 1 -Per Chr- –Block– -Rewrite- -Per Chr- –Block– –Seeks–Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CPHermes.local 7264M 764 98 565816 48 173112 23 3087 82 381238 23 408.3 10Latency 17417us 152ms 165ms 155ms 272ms 404msVersion 1.96 ——Sequential Create—— ——–Random Create——–Hermes.local -Create– –Read— -Delete– -Create– –Read— -Delete– files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 12744 32 +++++ +++ +++++ +++ 22131 63 +++++ +++ +++++ +++Latency 226ms 205us 8177us 14618us 144us 6156us[/code]Ich verstehe immer noch nicht warum da schneller geschrieben werden kann, als gelesen.spew -d -i 5 –read-after-write -b 8m 3g spewtest[code]Iteration: 1 Total runtime: 00:00:04WTR: 664118.34 KiB/s Transfer time: 00:00:04 IOPS: 81.07Iteration: 1 Total runtime: 00:00:13RTR: 366451.78 KiB/s Transfer time: 00:00:08 IOPS: 44.73Iteration: 2 Total runtime: 00:00:18WTR: 671850.29 KiB/s Transfer time: 00:00:04 IOPS: 82.01Iteration: 2 Total runtime: 00:00:26RTR: 366100.79 KiB/s Transfer time: 00:00:08 IOPS: 44.69Iteration: 3 Total runtime: 00:00:31WTR: 658596.59 KiB/s Transfer time: 00:00:04 IOPS: 80.40Iteration: 3 Total runtime: 00:00:39RTR: 367955.57 KiB/s Transfer time: 00:00:08 IOPS: 44.92Iteration: 4 Total runtime: 00:00:44WTR: 647762.96 KiB/s Transfer time: 00:00:04 IOPS: 79.07Iteration: 4 Total runtime: 00:00:53RTR: 368113.21 KiB/s Transfer time: 00:00:08 IOPS: 44.94Iteration: 5 Total runtime: 00:00:58WTR: 660796.70 KiB/s Transfer time: 00:00:04 IOPS: 80.66Iteration: 5 Total runtime: 00:01:06RTR: 365322.40 KiB/s Transfer time: 00:00:08 IOPS: 44.60[/code]Kann mir das jemand erklären??Hier noch die Skripte die ich zum einlesen und generieren der Dateien genutzt habe. [spoiler][code]#!/bin/bashfunction dddirectory(){echo “$1″cd “$1″for file in *do if test -d “$file”; then dddirectory “$file” else dd if=”$file” of=/dev/null &>/dev/null fidonecd ..}datedddirectory $1date[/code]Aufrufen z.B. mit “time scriptname /path/to/dir”[code]#!/bin/bashrm -rf raid/small/*for i in 1 2 3domkdir raid/small/$ifor j in 1 2 3 4 5 6 7 8 9 10domkdir raid/small/$i/$jfor k in 1 2 3 4 5 6 7 8 9 10domkdir raid/small/$i/$j/$kfor l in 1 2 3 4 5 6 7 8 9 10domkdir raid/small/$i/$j/$k/$lfor m in 1 2 3 4 5 6 7 8 9 10dofor n in 1 2dodd if=/dev/urandom of=raid/small/$i/$j/$k/$l/$m$n count=100 &> /dev/nulldonedonedonedonedoneecho $(( $i * 20000 ))done[/code]Verzeichnisse sollten angepasst werden.[/spoiler]

Es hat sicherlich irgendwas mit Cache zu tun. Ich habe den spew test nochmal mit 16gb ausgeführt. Schreiben ist immer noch schneller (zwar nur noch ca. 150MB/s aber weniger als oben!). Ich kann mir nicht vorstellen, dass er bei 16GB am Ende irgendwie noch was durch Caching rausholt, aber so sei es halt. Vor allem beobachte ich das mit iotop und die Leistung schwankt immer um 500MB/s (sowohl am Anfang, als auch am Ende).Deaktiviere ich alle Caches, sackt die Performance total ab und ich komme nur noch auf 80MB/s in beide Richtungen. Deaktivieren ist also ohnehin keine Option.Ich belasse es jetzt auch dabei. Die Werte (zumindestens lesend) decken sich ja mit euren ~50MB/s je Platte im Raid, wobei Raid6 bei mir auch etwas langsamer als Raid5 war, da von einer Platte weniger gelesen werden kann.Ich hab gerade nochmal getestet, wie schnell drei gleichzeitige lesende Zugriffe sind. 3x dd liefert ca. 3x 88MB/s. Mit der sequentiellen Leistung kann ich wohl Zufrieden sein.

Hi,

Zoldan;468029 said:
Es hat sicherlich irgendwas mit Cache zu tun.

Ich vermute das es auch (vor allem) mit dem Weg der Daten im Betriebssystem selber zu tun hat. Vermutlich ist das NULL-Device richtig gut implementiert, sodass es keine aufwändigen Prozesse braucht, bzw. unnötige Ressourcen frisst.

Man sollte auch das Caching von Linux selber nicht auszer Acht lassen, jedes GB Hauptspeicher haut rein, daher führt man solche Tests besser mit einem Kernelsetting “/mem=256k” aus, um die Messungen durch den Hauptspeicher nicht zu verfälschen.

Zoldan;468029 said:
Deaktiviere ich alle Caches, sackt die Performance total ab und ich komme nur noch auf 80MB/s in beide Richtungen. Deaktivieren ist also ohnehin keine Option.

Richtig, daher auch die unbedingte Empfehlung solche Setups mit einer BBU, bzw. besser einer USV (engl. UPS) zu betreiben.

Zoldan;468029 said:
Ich belasse es jetzt auch dabei. Die Werte (zumindestens lesend) decken sich ja mit euren ~50MB/s je Platte im Raid, wobei Raid6 bei mir auch etwas langsamer als Raid5 war, da von einer Platte weniger gelesen werden kann.

50MB/HD sind ein guter Anhaltswert, darunter ist was faul, darüber ist alles Spasz ;). Allerdings hat man im RAID6 ALLE Platten zum lesen, jedoch nur zwei weniger zum (Nutz-)Daten schreiben. Reine Lesegeschwindigkeit sollte sich nur gering bis gar nicht unterscheiden.

Zoldan;468029 said:
Ich hab gerade nochmal getestet, wie schnell drei gleichzeitige lesende Zugriffe sind. 3x dd liefert ca. 3x 88MB/s. Mit der sequentiellen Leistung kann ich wohl Zufrieden sein.

Jo, man sollte auch keine überzogenen Vorstellungen haben, besonders die synthetischen Tests der Hardwarehersteller erzeugen manchmal ein total verfälschtes Bild der Leistung. 3x88MB/s ist wirklich ordentlich!

Sc0rp

PS: bin bald aus dem Urlaub zurück und dann gehts mit der BiGBOX endlich weiter 🙄

Das komische waren nicht die Tests mit dem null device. Die finde ich eigentlich plausibel.

Tagchen,
ich werfe mal schnell zwei neue Infos in den Pool, mehr für mich aber auch für schwer Interessierte:

Western Digitals Erklärung zum Unterschied von Desktop vs. RE Platten:
–> http://wdc.custhelp.com/app/answers/detail/a_id/1397
(könnte man auch als Geldschneiderei verstehen …)

Und eine Studie von Google Research über das Fehlverhalten von Festplatten:
–> http://labs.google.com/papers/disk_failures.pdf
(beim Überfliegen recht interessant, aber Englisch)

Beides unkommentiert (aka ungeschminkt) und wertungsfrei …

Sc0rp

Mal wieder ein Update im Thread … 😉

Mit der kommenden Linux-Version 3.2 sollte man anscheinend BTRFS halbwegs sicher einsetzen können:

-> http://www.heise.de/open/artikel/Kernel-Log-Linux-3-1-rueckt-naeher-1357838.html (Absatz Kernel, zweiter Stichpunkt)

Dann können wir mal XFS (tuned) gegen BTRFS antreten lassen …

Sc0rp

ps: ich bin leider nach meinem Urlaub nicht bei meiner BiGBOX weitergekommen … Auto kaputt, Kühlschrank kaputt und nune auch noch der Fernseher *sigh*

Hi alle,… und besonders drdope ;):Absatz: Episode VI: Fazit muss nochmal über arbeitet werden denn, der erste Punkt ist nicht direkt reproduzierbar – es fehlt die Erstellung der GPT ;)EDIT: die fehlende Zeile / der fehlende Befehl ist:[code](parted) mklabel gpt [/code]Sc0rpps: mein RAID6 im SUPAMAN ist total abgestürzt, zwei HDs waren FAILED, zwei fehlten ganz im RAID und zwei erkannte der Controller zumindest noch. Sämtliche Masznahmen irgendwas zu retten schlugen fehl -> 100% Datenverlust. Mal sehen wie lange es dauert die Backups vom Band zu ziehen … *sigh* … ich hasse es!

Hallo zusammen, erstmal danke für diesen guten Thread, der mir bis heute sehr gut geholfen hat.Ich habe eine Frage zu der Kombination XFS und RAID6-Plattenausfall. Bei einem Kunden ist eine Festplatte des RAID6 ausgefallen. Diese habe ich nach Anleitung von Adaptec im Betrieb getauscht und der Controller hat diese auch automatisch erkannt und wieder bespielt. Allerdings fiel der XFS-Mount trotzdem aus. Die einzige Möglichkeit war diesen mit xfs-repair -L zu reparieren (ohne den Parameter hat es leider nicht funktioniert).Nun, damit ich in Zukunft sowas vermeide, die Frage: Habe ich Depp was Falsch gemacht? Hätte ich den Mount unmounten sollen? Oder gar den Server runterfahren? Hätte ich damit den Ausfall des XFS-FS umgangen?

Hallo,

evilass;483091 said:
Hallo zusammen, erstmal danke für diesen guten Thread, der mir bis heute sehr gut geholfen hat.

Danke 😉

evilass;483091 said:
Ich habe eine Frage zu der Kombination XFS und RAID6-Plattenausfall. Bei einem Kunden ist eine Festplatte des RAID6 ausgefallen. Diese habe ich nach Anleitung von Adaptec im Betrieb getauscht und der Controller hat diese auch automatisch erkannt und wieder bespielt. Allerdings fiel der XFS-Mount trotzdem aus. Die einzige Möglichkeit war diesen mit xfs-repair -L zu reparieren (ohne den Parameter hat es leider nicht funktioniert).

Also erstmal: was sagt denn die Anleitung von Adaptec?
Zum Zweiten: das der XFS-Mount ‘trotzdem’ ausfällt, kann ich mir nicht erklären – finde ich höchst seltsam. Das einzige was mit einer kaputten Platte stirbt, sind höchstens die Daten in ihrem Cache. Diese sollten aber vom Controller problemlos ausgeglichen werden … könntest du in den Logs mal nachforschen, warum XFS Probleme hatte?

evilass;483091 said:
Nun, damit ich in Zukunft sowas vermeide, die Frage: Habe ich Depp was Falsch gemacht? Hätte ich den Mount unmounten sollen? Oder gar den Server runterfahren? Hätte ich damit den Ausfall des XFS-FS umgangen?

Erstens: kommt drauf an, was du genau getan hast 😉
Zweitens: Das kommt natürlich auf deinen Kunden an, wenn er bereit ist, die Downtime seines Servers zu akzeptieren, ist der sicherste Weg immer der Beste: unmounten, run-level ändern, RAID restrukturieren, Dateisystem überprüfen, mounten. Der Server an sich, muss dafür nicht runter gefahren werden – es sein denn, man möchte gleich ein Kernel-Update mitmachen 😉

Meine ersten RAID-Verbünde liefen auf ext2, damit hatte ich nie Probleme, wenn Platten ausgestiegen sind. Mein SUPAMAN hat jetzt XFS auf einem RAID6, da könnte ich mal eine Platte rausziehen … :fresse:

Sc0rp

Sc0rp;483167 said:
Hallo,

evilass;483091 said:
Hallo zusammen, erstmal danke für diesen guten Thread, der mir bis heute sehr gut geholfen hat.

Danke 😉

evilass;483091 said:
Ich habe eine Frage zu der Kombination XFS und RAID6-Plattenausfall. Bei einem Kunden ist eine Festplatte des RAID6 ausgefallen. Diese habe ich nach Anleitung von Adaptec im Betrieb getauscht und der Controller hat diese auch automatisch erkannt und wieder bespielt. Allerdings fiel der XFS-Mount trotzdem aus. Die einzige Möglichkeit war diesen mit xfs-repair -L zu reparieren (ohne den Parameter hat es leider nicht funktioniert).

Also erstmal: was sagt denn die Anleitung von Adaptec?
Zum Zweiten: das der XFS-Mount ‘trotzdem’ ausfällt, kann ich mir nicht erklären – finde ich höchst seltsam. Das einzige was mit einer kaputten Platte stirbt, sind höchstens die Daten in ihrem Cache. Diese sollten aber vom Controller problemlos ausgeglichen werden … könntest du in den Logs mal nachforschen, warum XFS Probleme hatte?

evilass;483091 said:
Nun, damit ich in Zukunft sowas vermeide, die Frage: Habe ich Depp was Falsch gemacht? Hätte ich den Mount unmounten sollen? Oder gar den Server runterfahren? Hätte ich damit den Ausfall des XFS-FS umgangen?

Erstens: kommt drauf an, was du genau getan hast 😉
Zweitens: Das kommt natürlich auf deinen Kunden an, wenn er bereit ist, die Downtime seines Servers zu akzeptieren, ist der sicherste Weg immer der Beste: unmounten, run-level ändern, RAID restrukturieren, Dateisystem überprüfen, mounten. Der Server an sich, muss dafür nicht runter gefahren werden – es sein denn, man möchte gleich ein Kernel-Update mitmachen 😉

Meine ersten RAID-Verbünde liefen auf ext2, damit hatte ich nie Probleme, wenn Platten ausgestiegen sind. Mein SUPAMAN hat jetzt XFS auf einem RAID6, da könnte ich mal eine Platte rausziehen … :fresse:

Sc0rp

Huch, ich hatte den Thread ganz vergessen. Sorry.
Also: In der Anleitung von Adaptec steht nur drin, dass ich das während des Betriebes einfach machen kann. Ich glaube auch irgendwie nicht, dass die beiden Vorkommnisse (Plattenausfall und XFS-Problem) irgendwie zusammengehören.

Hat denn das XFS ein eigenes Log oder muss ich das im Syslog nachschauen?

PS: Und? Hast Du einfach mal eine Platte rausgezogen? :fresse:

Re,

evilass;483983 said:
Also: In der Anleitung von Adaptec steht nur drin, dass ich das während des Betriebes einfach machen kann.

Ja, das funktioniert auch. Habe ich erfolgreich schon mit einigen Controllern praktiziert. Zuletzt mehrfach mit dem RAID6 meines SUPAMANs (EXT2/LVM) – da fielen häufig 2 von 6 Platten uas dem RAID6 … :fresse:

evilass;483983 said:
Ich glaube auch irgendwie nicht, dass die beiden Vorkommnisse (Plattenausfall und XFS-Problem) irgendwie zusammengehören.

Solange wir keine besseren Anhaltspunkte haben …

evilass;483983 said:
Hat denn das XFS ein eigenes Log oder muss ich das im Syslog nachschauen?

Gute Frage, müsste ich mal auf die Suche gehen, arbeite ja noch nicht lange mit XFS …

evilass;483983 said:
PS: Und? Hast Du einfach mal eine Platte rausgezogen? :fresse:

Bist du verrückt? Nachdem ich mein RAID6 komplett verloren hatte und Tagelang Backups durchforsten musste (Bänder sind schön geduldig … und sehr langsam), soll ich es gleich nochmal “gefährden”? Bin froh das ich die Ursache gefunden hab 😉

Sc0rp

ps: Spielereien an meinem SUPAMAN-RAID kommen erst in Frage, wenn meine BiGBOX wieder läuft … das kann aber wegen der Plattenpreise noch etwas dauern 🙁

🙂 Ich schaue parallel auch mal, ob ich ein Log finde.

Moin,

ich wollt auch mal wieder meinen senf dazu geben .. wo sich doch hier mal wieder was tut 🙂

Sc0rp;483989 said:
Bist du verrückt? Nachdem ich mein RAID6 komplett verloren hatte und Tagelang Backups durchforsten musste (Bänder sind schön geduldig … und sehr langsam), soll ich es gleich nochmal “gefährden”? Bin froh das ich die Ursache gefunden hab 😉

na woran lag es den wenn ich fragen darf .. hab ja selber auch ein RAID6 am laufen .. infos kann man nie genug haben 🙂

DrDoom

Hallo,

DrDoom;484261 said:
na woran lag es den wenn ich fragen darf .. hab ja selber auch ein RAID6 am laufen .. infos kann man nie genug haben 🙂

Kurz: (reiner) Hardwarefehler in der Verkabelung aka “Wackelkontakt”

Lang: mein RAID6 läuft in einem 2HE-Gehäuse von Chenbro (siehe Sig -> SUPAMAN) mit einer Lüfter-Midplane und einer SATA-Backplane. Die SATA-Kabel haben keine Verriegelung. Nun hatte ich vorher schon das Problem, das immer zwei Platten (die obersten zwei) aus dem RAID6 ausgetiegen sind, sich aber immer ohne Probleme wieder ins RAID6 integrieren liessen (natürlich mit einem sechsstündigen Rebuild verbunden). Soviel zur Einleitung ;).

Nun läuft mein Dual-Sockel-Dual-Core-Opteron-System auch zu BOINC-Races, und da die beiden Jungs ganz schön Abwärme erzeugen, habe ich zur letzten WCG-Aktion den Deckel abgemacht und die Teile auf Vollgas laufen lassen. Nach drei Tagen hab ich dann leider erst mitbekommen, das mein RAID6 abgestürzt war – diesmal allerdings komplett, das Log des Controller zeigte, das zuerst die beiden Verdächtigen (wie vorher) ausgestiegen waren, dann die nächsten zwei und zum Schluss wurden die beiden obersten gar nicht mehr vom Controller registriert …

Die Fehlersuche dauerte lange, aber ich konnte die Steckverbindung an der SATA-Backplane als Fehlergrund ermitteln – die Kabel liegen aufgrund der beängten Verhältnisse nämlich an den Gittern der Midplane-Lüfter an (und zwar sind die Oberen am Stärksten betroffen, da hier die Kraft des Knickes auch am Grössten ist), durch Wärme und Lüfter und Vibrationen (ohne Deckel stärker spürbar) haben sich diese Kabel leicht verschoben und dadurch Kontaktprobleme verursacht.

Mittlerweile habe ich die Kabel mittels Heisskleber fixiert, die SATA-Kontakte der Backplane nochmal geputzt (beidseitig) und seitdem keinerlei Probleme mehr … auch nach mehrmaligen (Neu-) Starts und Simulation obiger Zustände – keine Ausfälle/Probleme.

Sc0rp

Hallöchen,

Achso .. sowas ist ja auch immer fies, dachte das es vllt ein firmwareproblem der platte gewesen wäre .. weil mit meinem anderen rechner hab ich das öfter mal das (unregelmäßige abstände) das sich eine von den 2 platten im software Raid 1 verabschiedet .. hat bestimmt 3 monate gedauert es auf die firmware einzugrenzen .. und dann sagt samsung auch noch das sie das firmwareupdate nicht rausgeben können. naja .. und dann hat dell noch ein firmwareupdate für diese platte rausgegeben .. und das kann ich nicht installieren .. k.a. alles komisch .. ich kauf kein samsung mehr ..

MfG DrDoom

Re,
das mit den Samsung-Geraffel hat sich eh bald erledigt, gehört die Festplatten-Sparte jezze nich jmd anderes? War’s nicht Seagate?

Ich habe jetzt wieder zwei RAID6-Verbünde mit WDC-Platten (2TB und 3TB) an den Start gebracht, die scheinen ordentlich zu laufen. Sobald ich meine Workstation mit SSDs gepimpt habe, kommt noch’n RAID5 aus 4xSamsung HD204UI dazu (drei hab ich schon *sigh*)

Sc0rp

Moin leutz,

hab mich in letzter zeit mal ein bisschen zfs beschäftigt und wollte mal fragen was ihr davon haltet?
Ich meine über das Problem der Konsistenz der gespeicherten Daten habe ich mir schon oft gedanken gemacht. Zu diesem Thema wurde in diesem Thead afaik noch nicht viel gesagt.
und bei array +10TB sollte man ja auch schon irgendwie irgendwas machen, damit nich irgendwann mal fehlermelden kommen die sagen datei kaputt .. dann nützt einem alle RAID level auch nichts mehr. Und dank “zfs scrub” spart man sich dann ja endlich das backup vom backup.

ich habe auf jeden fall für mich entschieden das ich auf zfs umsteige, nur das wann ist noch offen. wenn ich meinen 9650SE gegen ein aktuelleres model austausche werde ich spätestens an die sache ran .. und dann wäre es cool vllt mal ein paar erfahrungen austauschen zu können.

MfG DrDoom

Moin drdope,

das trifft sich ja gut. 🙂

ich habe jedoch ein bisschen was anderes gelesen. Also sicher “frisst” ZFS mehr system ressis als ein herkömliches FS aber in der heutigen Zeit ist das ehr unwichtig weil die Leistung bei reinen Datengräbern eh brach liegt. Wenn man ZFS auch noch für die RAID berechnung und die Verschlüsselung verwendet ist das jedoch wieder etwas anderes, dann sollte schon etwas mehr leistung vorhanden sein. Aber wenn man wie du einen 1880 hat (und nicht Verschlüsselt) dann kann man mit dem doch ohne probleme ein RAID 6 auflegen und darauf ein ZFS knallen. für den scrub profitiert man von der mörder bandbreite die du mit onboard-spielerein nie und nimmer hinbekommst.

MfG DrDoom

Re,

DrDoom;485010 said:
hab mich in letzter zeit mal ein bisschen zfs beschäftigt und wollte mal fragen was ihr davon haltet?

Ich persönlich: nix. Habe mir den Wikipedia-Artikel mal durchgelesen und finde nix, was mich vom Hocker haut, abgesehen davon, das bestimmte Teil dieses Artikel mal wieder höchst fragwürdig, wenn nicht gar falsch sind.

DrDoom;485010 said:
Ich meine über das Problem der Konsistenz der gespeicherten Daten habe ich mir schon oft gedanken gemacht. Zu diesem Thema wurde in diesem Thead afaik noch nicht viel gesagt.

Warum auch, das ist ein generelles Problem und hat erstmal nix mit RAID-Verbünden zu tun!

DrDoom;485010 said:
und bei array +10TB sollte man ja auch schon irgendwie irgendwas machen, damit nich irgendwann mal fehlermelden kommen die sagen datei kaputt .. dann nützt einem alle RAID level auch nichts mehr.

Ist dir das schon mal passiert – ich meine rein durch den Einsatz eines RAID-Verbundes? Mir noch nie, weder mit Hard-, Soft- oder Fakeraids. Wenn, dann passiert sowas nur durch unkontrollierte Abstürze des Systems, und davor ist auch ZFS nicht gefeit. Und auch einzelne Festplatten sind davor nicht sicher. Man sollte hier die verschiedenen Ebenen der Datenkommunikation nicht durcheinander bringen oder egalisieren. Ein RAID-Verbund stellt lediglich eine Zwischenschicht her, in der viele einzelne physische Festplatten zusammengefasst werden (können). Mehr nicht.

DrDoom;485010 said:
Und dank “zfs scrub” spart man sich dann ja endlich das backup vom backup.

Und was soll das “Backup vom Backup” sein? Für die wichtigen Daten sollte man immer (mindestens) ein Backup haben/machen und das möglichst örtlich getrennt lagern. In diesem Sinne möchte ich darauf hinweisen, das ein “Backup” mehr als ein (ganzheitliches) Konzept zu sehen ist, als irgendein Stückchen Hardware. RAID ist kein Backup, nur eine zusätzliche Sicherungsschicht (je nach Level), der einem vor einem unmittelbaren Festplattenschaden bewahrt (und das wurde hier schon ausführlich behandelt!), mehr nicht. Man eliminiert damit den “Single Point of Failure” der einzelnen Festplatte.

DrDoom;485010 said:
ich habe auf jeden fall für mich entschieden das ich auf zfs umsteige, nur das wann ist noch offen. wenn ich meinen 9650SE gegen ein aktuelleres model austausche werde ich spätestens an die sache ran .. und dann wäre es cool vllt mal ein paar erfahrungen austauschen zu können.

Was hat der Controller damit zu tun? Das verstehe icke nich … Aber wenn du ZFS einsetzt, dann berichte uns bitte von deinen Erfahrungen!

Ich für meinen Teil werde sobald es geht BTRFS einsetzen, das ist Linux-nativ und scheint viele Nachteile von EXT[2,3,4] zu vermeiden und viele Vorteile von XFS zu nutzen.

Ein Dateisystem einzusetzen, das für 128bit RISC-Maschinen entwickelt wurde, schon von vorherein Performance-Einbussen auf 64bit CPUs proklamiert, vornehmlich zum Einsatz in Rechenzentren designed ist … ist mir dann doch etwas zu fett. Und warum soll ich auf einem Single-Server mit einem RAID-Verbund nochmal ein RAID-Dateisystem aufsetzen? Abgesehen davon, das es sinnfrei ist, wird vermutlich auch die Performance ganz schön leiden und es bringt keine zusätzliche Sicherheit und verschwendet zudem noch Platz.

Es gibt durchaus Anwendungsszenarien für ZFS, keine Frage. Wenn ich ein Rechenzentrum hätte (aka MegaUpload ;)) und dort EINEN Server (Host-System) habe, mit vielen via SAS-Expander angeschlossenen HD-Arrays (=zPools), da macht das Sinn. Oder sowas wie die grossen Cloud-Services (aka Amazon), da macht das Sinn (wie die Vergangheit zeigt, wird es da aber gerade nicht eingesetzt). Aber zH? Selbst für SOHO und Kleinunternehmen finde ich das oversized …

Sc0rp

@Sc0rpich weiß das alles, ich habe auch nie gesagt das ein RAID in irgendeiner weise ein Backup ist. RAID Levels schützen nur vor Plattenausfällen. Es gibt aber auch Fehlfunktionen .. das sich bit’s mal umdrehen oder ausversehen falsch geschrieben werden .. durch was auch immer. Aus statistischer sicht passiert sowas nicht so oft aber bei immer größer werdenden array mit immer mehr platten wird das ganz schnell mal mehr. Ich hatte sowas schon. das die konsistens der daten gelitten hat. die video container haben zwar eine fehlerkorrektur integriert, wenn ein paar bit’s von deinem stream fehlen fällt das garnich auf, und selbst wenn ein paar mehr fehlen kann er oft trotzdem noch das file abspielen mit kleinen aussetzern (skit), solche skits gibs auch bei mp3’s und auch mit jpegs ist mir das schon passiert das bits auch ohne fette system abstürtze verloren gegangen sind. Die konsistens der daten konnte bisher nur über ein backup sichergestellt werden. nun ist aber ein backup von einem +10TB Array eine recht kostspielige angelegenheit .. und hier kommt zfs. dank der CRC eigenschaften dieses Dateisystems tut sich nun endlich mal was auf dem gebiet der konsistens der daten. BTRFS ist zfs unter linux aber noch nicht ganz fertig .. zfs soll doch aber in opensolaris (ein AMD64 OS!) integiert sein .. warum also nicht? sicher gibs das auch für dickere dinger .. aber na und? schadet es den? das mit dem controller hab ich nur hingeschrieben weil der 9650er nur 2TB platten ab kann .. und ich ihn schon mit 8 platten bestückt hab (mein profil) also wenn die 12TB voll sind werde ich mir einen neuen kaufen und auf dem dann zfs oder BTRFS einsetzen. das FS ist selbstverständlich unabhängig vom controller .. ich hab aber auch nicht gesagt das es so istachso .. und unkontrollierte systemabstürtze .. genau davor schützt zfs auch .. das ist ja das tolle .. zfs schützt immer .. musst nur nach einem systemcrash einmal scrubben und fertig .. oder habe ich da was falsch verstanden? den das dateisystem schreibt ja beim schreiben auf die platte gleichzeitig noch die crc werte mit auf .. und so kann zu jedem zeitpunkt der aktuelle wert mit dem vom erstmaligen speichern verglichen werden und bei abweichungen kann die urspründliche datei wieder hergestellt werden. oder nicht? wenn ich also 1a dateien auf mein zfs schreibe .. dann bleibt die datei für immer und ewig in einem 1a zustand .. wenn platten ausfallen müssen hier natürlich die raid level greifen ..So und zu drdope ..es kann auch sein das ich da was falsch verstanden hab .. aber man muss doch nicht RAIDZ1 oder RAIDZ2 machen um zfs benutzen zu können oder? man kann das genauso wie man es gerne hätte anstatt von ext oder xfs einsetzen. und da man das kann kann man auch wunderbar richtige raid controller einsetzen .. und hat dann auch noch den vorteil das bei scrub alles etwas zügiger geht weil der controller hat viel mehr futt hat als so ein onboard mist.DrDoom

drdope;485113 said:
Was ich an dem FreeNAS/ZFS/Softraid viel interessanter finde ist, das man sich um den ganzen Kram wie Partitionierung/Alignment/Formatierung keine Gedanken mehr machen muß -> das macht FreeNAS.
😉

Das ist es doch aber was so viel spass macht .. dass kann man sich doch nicht nehmen lassen 🙂

drdope;485113 said:
Außerdem spart man sich den teuren Raidcontroller und die damit verbundenen Probleme (Stichwort “HDD-kompatibilität” -> gerade jetzt – wo es nur noch WD (Hitachi Storage gekauft) und Seagate (Samsung Storage gekauft) gibt – könnte das ein potentielles Problem werden…
🙁

Dazu habe ich gleich 2 Fragen.
1. Wie kommts zu dem sinneswandel? du bist quasi der Grund warum ich auf professionelle Controller trotz des vergleichsweise hohenpreis gewechselt habe. Ich sehe bis auf den Preis nur Vorteile. Richtige Controller haben auch Richtige Leistung (1-2 GByte/s). Größtenteils extreme zuverlässigkeit. Sehr gut skalierbar/flexibel. Ersetzbar .. zumindest leichter als ein MoBo .. ich hatte früher mal ein onboard raid mist ding .. da is das board kaputt gegangen .. und kein anderes board das ich ausprobiert hab konnte mit dem raid set was anfangen .. das war sehr frustierend .. und mainboards findet man nach 3 jahren oder so nich mehr .. du kannst aber heute noch 10 jahre alte raid controller kaufen .. mal ganz davon ab das ich persönlich glaube .. das ehe so ein server raid controller kaputt geht .. geht so ein mainboard 2 oder gar 3 mal kaputt .. is halt viel komplexer egro mehr points of failure 🙂

2. was is schlecht daran außer die sch**ß monopol-bildung so dass wenige über absprachen (auch wenn verboten) den markt regulieren und diktieren? ich seh das von der seite .. das es weniger schwierigkeiten wegen firmware etc gibt weil die controller hersteller nur noch mit 2 herstellern zusammen arbeiten müssen .. also langfristig wird es einfacher und vorteilhafter für den controller-hersteller und den entbenutzer (bis auf das preis diktat der monopolisten)

drdope;485113 said:
Auch der Raidcontroller als singulärer Point-of-Failure fällt weg -> da hat man privat ja eher selten Backupcontroller im Regal liegen.

Aber man kann sie eben noch jahre später ohne probleme bei ebay ersteigern .. für mich is das ein pluspunkt

drdope;485113 said:
Ich würde das ganze dann vermutlich so angehen, das ich mir 2 identische FreeNAS mit je 6x 4TB aufbaue.
Einen als NAS-Server, den anderen als Offline-Backup, das regelmäßig per rsync den eigentlichen Server spiegelt (auch das geht mit FreeNAS mit sehr wenigen Klicks im WebGUI).

Du hast jetzt schon 23TB .. mit nur 6 Ports kommt man doch auf die dauer selbst mit schweine teueren 4TB Platten nicht klar oder was?
ich meine du hast es ja quasi vorgemacht .. man hat einen 16 port controller .. da is ein 8 platten set dran .. wenn das irgendwann voll ist kann man ein neues 8 platten set aufmachen mit größeren platten und dann schiebt man seine daten einfach auf das neue und verkauft die kleinen platten .. diese taktik finde ich total genial und effizient .. vorallem wenn man so einen geilen controller hat wie du

aber wenn du deine daten wirklich auf so einem spielzeug-system ablegen möchtest und deinen 1880 veräußern willst sag bescheid 🙂

MfG DrDoom

Deine Befürchtungen mit den HDD-Preise teile ich. Ich könnte mir ejden morgen in den A- beißen, das ich im oktober mit dem kauf von weietren hdds gezögert hatte :(:(:(

Wie liegt das Supermicro X9SCL-F so im Verbrauch?
Wofür benötigst Du 32GB RAM im Fileserver? Nutzt Du das als Cache?

C202 kann ich gar nicht einschätzen, aber der Controller dürfte ja einiges gebraucht haben…KVM via LAN ohne zusatzhardware ist schon ein netztes Feature. Was benötigt man da auf der anderen Seite?

drdope;485154 said:
….momentan im meinem Server verbaut ist (Consumerboard; non ECC-RAM; keine Komponente ist für den Betrieb mit der anderen validiert etc..).
😉

das sehe ich als zweischneidiges schwert.
wie bereits erwähnt hab ich mit softwarelösungen schlecht erfahrungen gemacht .. und weil das eben nix anständiges ist gibs auch keinen anständigen support, dann sind eben alle daten weg .. wer sichergehen will oder muss das die daten heil bleiben muss eben profi-teile verbauen, das ist überall so .. sicher ist es nicht unbedingt von vorteil wenn man consumerbauteile mit profibauteilen zusammen betreibt .. aber es ist imho sicherer als wichtige daten bauteilen anzuvertrauen die für diesen zweck nich 100% geeignet sind. so ein hardware-raid-controller muss nur 1 sache machen .. für den fall das eine oder zwei platten (je nach raid level) ausfallen ein rebuild ohne fehler durchführen .. und das bekommen die meisten hin .. sollten sie auch bei den preisen 🙂 und sie sollten es auch tun wenn sie nicht für das verwendete MoBo validiert ist.

ein bekannter hat ein synology 15TB system .. das läuft .. ein anderer hatte ein älteres synology system .. da hat er schon mal 2TB daten verloren weil mit der firmware bei einem rebuild wohl irgendwas nich funktioniert hat .. ich hab selber keine erfahrungen und muss zugeben das beide synology-owner ehr wenig ahnung von allem haben .. aber wenn es um wichtige daten geht würde ich das keinem abgeschloßenen inselsystem zumuten das ich nich vollständig unter kontrolle hab ..

freenas ist wieder was anderes .. opensource und anpassbar .. aber auch hier gibs grenzen aber ich werde auf jeden fall auch mal einen blick riskieren .. man lernt ja nie aus ..
Ich soll für einen kollegen eine preiswerte storagelösung mit maximaler sicherheit zusammenbauen und einrichten .. nur leider fehlt mir atm die zeit .. wenn sich das ändert werde ich das thema wohl mal vertiefen und es wahrscheinlich für ihn auf diese weise lösen 🙂

drdope;485154 said:
Bei der derzeitigen Konsolidierung am HDD-Markt, habe ich auch mittelfristig bedenken, ob es zukünftig noch preiswerte Consumer-HDDs geben wird, die an Hardware-Raidcontrollern laufen (validiert werden ja eh nur “Serverplatten”).

Diese meinung teile ich nicht, jeder hersteller ist daran interessiert Umsatz zu machen. Große datacenter setzen auch massenweise Consumerplatten ein (weil Preis/Kapazität einfach stimmt .. da is es egal wenn ein paar platten rumzicken) .. und von daher sollten sowohl HDD Hersteller als auch controller Hersteller interesse an funktionierenden setups haben. wer sägt schon an dem ast auf dem man sitzt? Außerdem gibt es ja nun auch mehr als Areca .. LSI is zwar nicht mein favorit .. aber die machen zum teil auch brauchbare controller .. die zeit wird es zeigen .. ich will mal hoffen das du unrecht mit deiner prognose hast .. sonst hab ich bald keinen spass mehr an meinem hobby 🙂 und dann müsste ich das an den nagel hängen und die H0 wieder vom speicher holen 🙁

drdope;485154 said:
grad gelesen, vorher übersehen -> das Board unterstützt “nur” ECC RAM, kein registered ECC!

QeD spielzeughardware 🙂

MfG DrDoom

Um den Umsatz braucht man sich bei einem derart aufgeteilten Markt kaum sorgen machen. Irgendwo muß man ja die HDDs kaufen.
Da könnte es schon eher sein, wenn Google angepißt es kurzerhand Toshiba die Produktionanlagen “abulxxt” ist ja schließlich nur eine Frage des Preises…

Reg. Ram macht heutzutage eigentlich erst bei mehr als 8 Modulen Sinn bzw. im privaten Umfeld eigentlich gar nicht, da der Stromverbrauch dueltich höher ist. Da verbraucht dann der RAM mehr als eine sparsame CPU.

Tagchen,
im Forum wurde die Frage nach dem Unterschied zwischen RAID- und Non-RAID-Platten gestellt … sollten wir die TLER-Geschichte nicht auch hier hinzufügen? Vllt. als “Misc” oder “Related” mit einem einfachen Link?

Sc0rp

Hi Leute,

gestern habe ich einen neuen Server mit einem Areca ARC-1130 Controller an den Start gebracht, DATEN-RAID6 läuft mit 8x WDC Red 3TB … Build lief in 8:40h durch 😉

Was geht eigentlich bei Euch so? (zu drdope schiel) …

Sc0rp

Hallo zurückIch habe 2011 basierend auf diesem Artikel bei einem Kunden ein 17 Terabyte netto raid6 angelegt und mit XFS formatiert. Läuft seitdem super! Hat bis jetzt kein einziges Mal Ärger gemacht. Ich würde es jederzeit wieder machen.Allerdings muss ich gestehen, ich kenne mich mit den Wiederherstellungsmöglichkeiten für XFS nicht besonders gut aus. Deshalb würde ich eher immer mal eben schnell die Sicherung zurück spielen, als mich 3 oder 4 Tage damit zu beschäftigen.Spaß habe ich eher mit NETATALK Und den neuen Apple Betriebssystem. Ist auch ein Thema für sich, läuft zum Glück auch sehr stabil. Einfach ist allerdings anders.

Hallo zusammen,ich bin neu hir im Forum, daher stelle ich mich kurz vor. Ich heiße Michael, komme aus Köln und arbeite im Bereich Medien. Wer noch mehr wissen will kann gern fragen.Nun zum Grund meines Anliegens. Ich bin dabei mir für mein Videohobby eine bezahlbare Speicherlösung zu schaffen. Dazu habe ich auch schon ein paar Anschaffungen gemacht. Ich möchte gern meine Video/Audiodaten auf LTO-4 sichern mit TAR oder ähnlichem. Die Datenmenge ist entsprechend hoch (ca. 25GB/stunde ohne Metadaten für SD und 100GB/stunde für HD) Hierzu habe ich einen kleinen IBM Server angeschafft x3100 M4 mit Xeon E3-1230v2, 16GB Ram, 1x LSI 9271-8i für HDD’s und ein IBM 6Gbit SAS Controller für das LTO-4 Laufwerk, Festplatten sind 2x SATA WD1000DHTZ 1TB 10.000rpm im Raid1 (System HDD) und 2x SAS 4TB Seagate 7200rpm ST4000NM0023 512byte/sektorRaid0 (zum füttern des Laufwerks und Temporäre Ablage, daher auch nur Raid0)Als Betriebsystem habe ich mich für Centos 6.5 entschieden, da ich RHEL6.5 auf der Arbeit einsätze und ich damit ganz gut klar komme.Nun meine Frage, welches Dateisystem wäre aktuell das “Mittel der Wahl” für das Temporäre Speichern großer Daten und möglichst auch ausreichend Perfomant für das Füttern des Laufwerks mit 120MB/s. Ich bin für Vorschläge offen. Wenn hier noch Daten von Festplatten oder Controllern für eure Zwecke hier haben wollt, einfach fragen ich geb euch was ich kann.GrußMichael

Mal ne Gegenfrage, warum hast du nicht LTO5 und dann LTFS genommen? Dann könntest du direkt aufs Band schreiben und lesen als wäre es eine langsame Festplatte. Gerade für ein Archiv ist das nicht schlecht.

Hallo,das will ich dir gern sagen. Zum einen weil ich ein fast neues LTO-4 Laufwerk für 200 euro bekommen habe und die Bänder neu für 15 euro kaufen kann. Das war eine preisliche Sache, da der “Rest” schon Geld genug gekostet hat.Zum LTFS: LE und SE setzen wir im Betrieb ein.Ist ganz nett, aber Systemübergtreifend eher eine Bremse.Beispiel ein Verzeichnis wird unter RHEL 5.6 Linux mit aktueller Version LTFS SE geschrieben und an einer Windows Maschine mit ebenfalls aktueller Version komplett gelesen. Einfach alles Markieren und rüber schieben, resultat durchschnittliche Datenrate 12-20kb/Sek. weil das Band viel Spult und die Daten nicht in der Reihenfolge gelesen werden wie sie geschrieben wurden. Nachteil eines Linearen Datenträgers der über Software als randomaccess Datenträger dargestellt wird. So meine Erfahrungen und die meiner Kollegen im Videobereich mit LTFS. Nebenbei, wir arbeiten mit IBM an der Weiterenwicklung des LTFS systems und der Verwaltung schon eine Weile. Aktuell schlage ich mit meinen TSM Servern jede LTFS Library um einiges in Sachen Schreib/Lese Performance. Aber da ist es eben auch mit Datenbank dahinter und kein selbstbeschreibendes Medium wie bei LTFS. Nebenbei ist es mir ganz recht mit einem so minimalistischen und sicher alten Programm wie Tar zu arbeiten, es ist weniger Evolution unterworfen und wird sicher einwandfrei gelesen, solang man die Blockgröße kennt.GrußMichael

Ich hab da mal ne Frage zum XFS Filesystem. Ich habe nun mein 8TB HW Raid0 mit GParted eine Partition angelegt und mal testweise mit GParted formatiert als XFS. Über xfs_info bekomme ich für sunit und swidth = 0meta-data=/dev/sdb1 isize=256 agcount=32, agsize=61038560 blks = sectsz=4096 attr=2, projid32bit=0data = bsize=4096 blocks=1953233920, imaxpct=5 = sunit=0 swidth=0 blksnaming =version 2 bsize=4096 ascii-ci=0log =internal bsize=4096 blocks=521728, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0Wenn ich mit Parametern manuell formatiere sagt mk2fs.xfsSpecified data stripe width XXX is not the same as the volume stripe width 8Egal was ich angebe es steht immer “stripe width 8″Wo stehe ich auf dem schlauch? Kann mich einer von euch mal erleuchten?Aktuell raid 0 aus 2x ST4000NM0023 (512b/sector) mit stripe size 512kb.Falls jemand mehr wissen muss oder will, einfach fragen.GrußMitch

Hallo,

Wenn ich mit Parametern manuell formatiere sagt mk2fs.xfsSpecified data stripe width XXX is not the same as the volume stripe width 8Egal was ich angebe es steht immer “stripe width 8”

Welche Paramter nimmst du hier? Bitte poste mal die Eingabezeile bzw. die Einzelheiten (was stellst du in GParted ein?).Sc0rpEDIT:du hast den Artikel im ersten Post gelesen?(Episode II: Formatieren des Arrays mit mkfs.* -> Spoiler -> 2. was sollte man beim Anlegen beachten? -> 2.1. XFS -> Zitat:

Alternatively, you can use “sunit” instead of “su” and “swidth” instead of “sw” but then sunit/swidth values need to be specified in “number of 512B sectors”!Note that xfs_info and mkfs.xfs interpret sunit and swidth as being specified in units of 512B sectors; that’s unfortunately not the unit they’re reported in, however. xfs_info and mkfs.xfs report them in multiples of your basic block size (bsize) and not in 512B sectors.Assume for example: swidth 1024 (specified at mkfs.xfs command line; so 1024 of 512B sectors) and block size of 4096 (bsize reported by mkfs.xfs at output). You should see swidth 128 (reported by mkfs.xfs at output). 128 * 4096 == 1024 * 512.When creating XFS filesystem on top of LVM on top of hardware raid please use sunit/swith values as when creating XFS filesystem directly on top of hardware raid.

Denn die 4KiB-Blöcke von XFS durch “stripe width 8” geteilt ergibt deine Sectorsize 512BEDIT2:Deine Zeile müsste heissen:

mkfs.xfs -d su=512k,sw=2 /dev/sdxy

Sorry für die vielen EDITs – ich musste immer in den ersten Post springen und nachguggen, ich hab das verdammt lange nicht mehr gemacht (meine XFS-RAIDs laufen alle ohne Probleme :P)

Hallo Sc0rp,Danke für deine Antworten. Die Edit’s kann ich nochvollziehen. Es ist nicht so, dass ich vollkommen unbedarft bin.Ich habe von 32-512 für “su” alles durch. Ich kenne auch Ähnliches bei dem bei uns auf der Arbeit verwendeten GPFS Filesystem, welches unter meiner Fuchtel steht. Daher kam es mir etwas merkwürdig vor das ich immer die besagt Meldung bekommen habe “Specified data stripe width XXX is not the same as the volume stripe width 8” Ich habe auch versucht in sunit/swidth anzugegeben. Der Erfolg bei manchem Test war 32MB/sec minimal Transferrate. Wenn ich heute leer geschaufelt habe werde ich das Raid0 mal mit den von dir angegebenen Parametern mal formatieren. Aktuelle Stripe Size 512KB, Ob das die vermeintlich beste Größe ist wird sich hoffentlich zeigen. Falls du oder jemand anderes weitere/andere Vorschläge hast/habt nur raus damit.Zunächst mal vielen lieben Dank an alle Interessierten!!! Das meine ich ganz Ernst mit dem Dank!!!GrußMichael

Re,ein bisschen Googlen bringt auf jeden Fall etwas zu Tage:siehe http://oss.sgi.com/archives/xfs/2012-12/msg00229.html>>> deine “sectsz=4096” wird offensichtlich falsch erkannt (sollte ja auf 512 stehen), und damit kommt XFS nicht klar …Nun kannst du versuchen, den Teiler 8 (4096/512) reinzurechnen oder die Sectorsize beim Erstellen mit angeben …EDIT:probiere mal die Sektorgröße anzugeben:

mkfs.xfs -s size=512 -d su=512k,sw=2 /dev/sdxy

Alternativ den Faktor 8 einzurechnen, entweder über su=128 (512KiB-Stripe / 4KiB sectsize) oder mittels sunit=128, da ich kein XFS-Entwickler bin, kann ich dir nicht sagen, welches besser wäre :PSc0rp

Meintest du so in etwa? mkfs.xfs -f -s size=512 -d su=256k,sw=2 /dev/sdb1mkfs.xfs: Specified data stripe unit 512 is not the same as the volume stripe unit 8meta-data=/dev/sdb1 isize=256 agcount=32, agsize=61038528 blks = sectsz=512 attr=2, projid32bit=0data = bsize=4096 blocks=1953232896, imaxpct=5 = sunit=64 swidth=128 blksnaming =version 2 bsize=4096 ascii-ci=0log =internal log bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=64 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0

So,hier das Ergebnismkfs.xfs -f -d su=512k,sw=2 /dev/sdb1mkfs.xfs: Specified data stripe unit 1024 is not the same as the volume stripe unit 8meta-data=/dev/sdb1 isize=256 agcount=32, agsize=61038464 blks = sectsz=4096 attr=2, projid32bit=0data = bsize=4096 blocks=1953230848, imaxpct=5 = sunit=128 swidth=256 blksnaming =version 2 bsize=4096 ascii-ci=0log =internal log bsize=4096 blocks=521728, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=01:1 rein kopiert von der Bash. Was nu?

recht hast du, tut mir leid ich bin etwas im stress. Nebenbei noch am einspielen und material sichten. hab nich genug hingegschaut, mach es gleich richtig.Zu dem was ich hier an “Hardware” habe.Die besagten Festplatten Seagate ST4000NM0023 haben 512B Blöcke, so auf der Seite des Herstellers angegeben. Ich habe die Stripe Size im MegaRaid Storage Manager mit 512KB für das entsprechende Volume stehen, wie bei der erstellunge angegeben (ich hab extra noch mal nachgesehen).Falls du gern was getestet haben willst um mehr zu wissen oder zu kennen, dann nur raus damit.DANKE für den Hinweis für den Blinden!!!

mein Raidcontroller ist ein LSI 9271-8i mit 1GB Cache. Es sind 4 Platten angeschlossen.2x ST4000NM0023 (aktueller Diskussionsgegenstand)2x WD1000WDHZ0 Systemplatte Raid1 (4K Sectoren)

Wie kommst du auf einmal 256k Stripe-Size? Waren das nicht erst 512k? Hast du das RAID umformatiert?Evtl. kannst du auch die sunit mitangeben (hab ich noch nie probiert), fest steht, das dein mkfs.XFS die Werte durcheinanderbringt, welche Kombi nun passt kann ich dir nicht verraten.Offensichtlicherweise hast du einen RAID-Controller zwischen Platte und System, bzw. ein Software- oder Fake-RAID, der die Sektorsize von 512B (der HDD) auf die erkannten 4096B bringt … liege ich damit richtig?Musst mal durchprobieren:1) falls sunit doch nicht auf 512B-Blöcken basiert:

-b size=4096 -d su=512k,sw=2,sunit=128

1) falls sunit doch auf 512B-Blöcken basiert:

-b size=4096 -d su=512k,sw=2,sunit=1024

Wenn du deine Stripe-Size anpasst, musst du natürlich auch die Werte für su und sunit anpassen. Falls das nix hilft, könntest du noch die Stripe-Size des RAID-Verbundes ändern und erneut testen.Dann geht mir auch langsam der Stoff aus ;)Sc0rpEDIT:… diesmal wegen Kurzzeitvergesslichkeit …- alternativ mal den Wert für 512k durch 524288 (Bytes) ersetzen

Re,
jo, ich hab noch was gefunden:
https://raid.wiki.kernel.org/index.php/RAID_setup
(letzter Absatz = XFS, der Artikel geht zwar ums Software-RAID unter Linux, aber XFS ist das ja egal 😉

Fakt 1: die Festplatten haben zwar 512B physische Sektoren, aber dein Controller macht daraus 4096B (also schreibt/liest er auf jeden Fall 8 Blöcke auf einmal) und damit nutzt auch XFS 4KiB

Fakt 2: die Werte aus der xfs_info stimmen manchmal nicht ganz – hier muss die richtige Kombination gefunden werden, leider sind die Informationen zu sunit und swidth nicht ganz einfach, da hilft viel lesen UND probieren 😉

Probieren:
a) Parameter “-d sunit=128,swidth=256”
b) Stripe-Size reduzieren (RAID umformatieren)
c) welche Einstellung hat dein Controller für das “Big Disk”-Problem alter NT-Versionen? (es gibt da zwei Optionen: 4k Blocks for older Windows-Versions und LBA64, es sollte auf jeden Fall Letztere sein!)

Sc0rp

Sc0rp

a) Versuche ich heute Abend hini zu bekommenb) Wie würdest du es im Detail vorschlagen für meinen Anwendungszweck 50Mbit Video zzgl. Audio auf LTO 4 schreiben?c)Ich habe grade mal im PDF des LSI nachgeschaut was das LBA angeht.Dort steht:”These RAID controllers support 64-bit logical block addressing (LBA), which makes it possible to connect a large number of drives to the RAID controller, directly and through expanders. However, the actual number of drives that you can attach depends on the limits listed in thistable rather than by actual RAID volume capacity.”

Hier einmal was parted ausgesprckt hat ohne partition, nach umstellung auf 256K stripe sizeModel: LSI MR9271-8i (scsi)Disk /dev/sdb: 8000GBSector size (logical/physical): 512B/4096BPartition Table: gptNumber Start End Size File system Name Flags(parted) Bin gespannt was du im Detail vorschlägst zur FormatierungGruß und DankeMichaelDu hast nun die Gelegenheit mir exakt zu sagen wie ich das Raid0 Partitionieren soll und wie es formatiert werden soll.Dann wird gestestet und ggf wieder umformatiert, wenn du du willst.

Re,
b) nunja, das ist immer die heilige Frage – in diesem speziellen Fall solltest du nur die Stripe-Size reduzieren, um zu sehen ob XFS bei 256k keine (oder andere ;)) Probleme hat, sprich ob XFS mit den 512k Probleme macht
c) ich habe gestern beim Überfliegen der PDF auch nix gefunden, wo man das Umstellen könnte, aber eigentlich sollte dein Controller bei LBA64 die Sektorengrösse 512B durchreichen – und nicht 4KiB … daher würde ich mal bei parted die Infoseite / Details des Datenträgers anguggen wollen:
[code]
$ sudo parted /dev/sdb
[sudo] password for :
GNU Parted 2.3
Verwende /dev/sdb
(parted) print
[/code]

Sc0rp

Ich schlüssele das mal auf:Bei mir:[code]Stripe-Size = 128KSectsize = 512Bxfs_bsize = 4096xfs_sunit = 32 (128K / 4KiB = 32) xfs_swidth = 192 blks (= 6x sunit, da RAID6 mit 8 HDDs nur 6 Datenplatten hat)[/code]Adaption auf dich (erster Versuch):[code]Stripe-Size = 256KSectsize = 4096Bxfs_bsize = 4096Bxfs_sunit = 64 (256K / 4KiB = 64) xfs_swidth = 128 blks (= 2x sunit, da RAID0 zwei Datenplatten hat)[/code]Daraus müsste für dein XFS folgen:[code]mkfs.xfs -b size=4096 -s size=4096 -d su=64,sw=2[/code]Sc0rpEDIT:Ich habe keine extra Metadatenplatte … evtl. habe ich das die Metadatensektion etwas angepasst um a) mehr Platz zu haben und b) um sie auf mein RAID6 anzupassen (“zu tunen”) – aber das ist wirklich lange her, kann mich nicht mehr dran erinnern … und das Ding läuft richtig gut und stabil.

Ich gebe mal mein XFS-RAID zum Besten:[code]sc0rp@SUPAMAN:~$ sudo xfs_info /dev/sdcxfs_info: /dev/sdc ist kein eingehängtes XFS-Dateisystemsc0rp@SUPAMAN:~$ sudo xfs_info /dev/sdc1Metadaten =/dev/sdc1 isize=256 agcount=17, agsize=268435424 blks = sectsz=512 attr=2Daten = bsize=4096 Blöcke=4394530560, imaxpct=5 = sunit=32 swidth=192 blksBenennung =Version 2 bsize=4096 ascii-ci=0Protokoll =Intern bsize=4096 Blöcke=521728, Version=2 = sectsz=512 sunit=32 blks, lazy-count=1Echtzeit =keine extsz=4096 Blöcke=0, rtextents=0sc0rp@SUPAMAN:~$ sudo parted /dev/sdc printModell: Areca DATEN-RAID6 (scsi)Festplatte /dev/sdc: 18,0TBSektorgröße (logisch/physisch): 512B/512BPartitionstabelle: gptNummer Anfang Ende Größe Dateisystem Name Flags 1 1049kB 18,0TB 18,0TB xfs DATEN-RAID6sc0rp@SUPAMAN:~$ root@SUPAMAN:~# ARECA/cli64 Copyright (c) 2004-2013 Areca, Inc. All Rights Reserved.Areca CLI, Version: 1.12.0, Arclib: 342, Date: Mar 18 2013( Linux ) S # Name Type Interface==================================================