Samsung Raid mit Seagate erweitern

[terror_gnom]

Moin Moin

Mir ist aus meinem Raid5 Verbund mit 5 Platten eine Ausgefallen.
Bisher waren alles Samsung HD204UI. Da es Samsung ja nichtmehr gibt, wird aus der RMA vermutlich ne Seagate zurück kommen.
Haben die Seagate ST2000DL004 (welche ich vermutlich erhalte) eine selbe oder größere Anzahl Blöcke wie die Samsung?
Ich hab blöderweise die Samsungplatten bis auf den letzten Block ausgereizt
Muss ich schauen, ob ich noch ne Samsung auftreib oder kann ich die Seagate problemlos verwenden?

Und gibts sonst noch was bei nem mdadm raid zu beachten?

Der PC ist momentan ausgeschalten und zerlegt. Ein Backup (ja, ja ich weis) ist leider nicht vorhanden (aber zumindest von den wichtigsten Sachen)

Dank und Gruß

terror

 

[bu1137]

Festplatten sind scheinbar seit Jahren bereits alle gleich gross. Sollte also kein Problem sein.

 

[Chesterfield]

ja muesste gehen denk ich auch !

 

[Fallaxia]

Du kannst andere, gleich große Festplatten einbauen, aber ich würde es persönlich nicht machen.
Einfach aus dem Grund da es Dir die Performance zerstören kann abhängig davon wie die HDDs geschriebene Daten an den Controller zurückmelden kann es dazu führen dass auch bei theoretisch gleich schnellen Platten starke Performanceverluste auftreten.

Bei einem Software Raid aber wohl sicher verschmerzlich - von daher: Ja, Du kannst die Seagte nehmen.

Die Samsung Festplatte gibt es aber noch zu erwerben:

http://ad.zanox.com/ppc/?23599354C1856912894T&ULP=B0042SGDVG

In diesem Fall von Amazon, klick mal in dem Angebot auf "1 B-Ware & 2. Wahl" - dort findest Du eine von Samsung refurbished HDD, also einen Samsung Datenträgertausch. Die kannst Du bedenkenlos einsetzen - falls mal was damit sein sollte ist Amazon ja sehr freundlich und erstattet Dir den Kaufpreis bzw. sendet Dir eine Baugleiche neu zu - das Raid 5 ist ja für sowas gedacht.

Grüße
Fallaxia

 

[Ernst@at]

Das Konsortium der Festplattenhersteller hat sich schon vor vielen Jahren darauf geeinigt, Festplatten einer bestimmten Kapazität nur mehr mit einer genau festgelegten Anzahl an Sektoren zu vertreiben.
2TB Festplatten haben daher bei allen Herstellern genau 3.907.029.168 Sektoren.

Bei Tausch einer der Platten eines RAID5 sind im Falle, dass die neue Platte gleiche Drehzahl hat, aber höhere Datendichte besitzt(was bei Wechsel auf die Seagate zu erwarten ist) aus dieser Eigenschaft keine Performanceverschlechterungen zu erwarten - eher eine leichte Verbesserung.
Da die Neue aber im Advanced Format (4K physische Sektoren) arbeitet, kann bei Schreiboperationen ein Nachteil daraus entstehen. Selbst bei korrektem Alignment der Partitions werden vom System tw. Schreiboperationen abgesetzt, welche keine durch 8 teilbare Anzahl an Sektoren betrifft. Wenn diese Daten oder die Parity auf der Neuen liegen, bedeutet es eine zusätzliche Umdrehung und 8,3ms zusätzliche Wartezeit je I/O.

 

[Fallaxia]

Wie immer kam von Ernst@at eine gute, ausführliche, technische Erklärung.

 

[terror_gnom]

Ok, Vielen dank Dann frag ich mal im Freundeskreis rum, ob jemand ne gebrauchte Samsung gegen ne neue Seagate tauschen will^^

 

[Ernst@at]

Wie immer kam von Ernst@at eine gute, ausführliche, technische Erklärung.

Naja, manchmal schreibt er auch Unsinn - zB hier

Die angedrohten Performanceeinbußen hören sich schlimmer an, als sie sind.

Ich hab blöderweise die Samsungplatten bis auf den letzten Block ausgereizt

Wenn Du beim geizen sogar auf das 1MB-Alignment der Partitions verzichtet hast, dann schon. Denn bei nonaligned Partitions ist dann auch jeder Write-I/O unaligned.

Ansonsten ist der Grad der Auswirkung vom verwendeten Filesystem, und den Definitionsparametern des RAID abhängig. Im Win würde mit NTFS-Clustersize 64K bei 5 Platten im RAID5 mit einer Stripesize von 16K das beste Ergebnis beim seq. Schreiben rauskommen - nahezu 4-fache Geschwindigkeit gegenüber einer Einzelplatte, etwa gleich der seq. Leserate.
Der Trick dabei: die Datencluster sind so 64K aligned, beim Schreiben wird daher bei fast jedem I/O ein komplettes Stripeset beackert, womit auch das Parity-Stripe nicht erst durch vorangehendes Lesen ermittelt werden muss, sondern sofort geschrieben werden kann.

Bei ext3-Filesystemen kann man das nicht anwenden, bei ext4 aber mittels Erhöhung der cluster blocksize via bigalloc schon.

Die im Post#5 genannten Nachteile treten bloß bei NTFS, nicht aber bei ext3/ext4 auf, weil die nicht so vertrottelt wie NTFS mit 4K-unaligned Zugriffen auf den Index, die Bitmap und das Journal arbeiten.

Hängt also vom verwendeten Filesystem ab, ob bei Tausch gegen einen AF-Platte die Performance beim Schreiben sinkt. Da auch nur im prozentuellen Häufigkeitsverhältnis
der Zugriffe
(# unaligned Index-,Journal-,Bitmap-Operationen/#aligned Datenclusteroperationen)
und im Durchschnitt weniger als 1% Performanceverlust - außer bei häufiger Bearbeitung vieler kleinster Dateien.

Also kein Grund, Panik deswegen zu schieben - außer, Du hast unaligned Partitions

Zur Optimierung eines mdadm-RAIDs habe ich in meinem Link-Bauchladen noch Folgendes gefunden: Script to tune mdadm raid5

 

[terror_gnom]

Ok... hier fliegen mir zu viele Begriffe durch die gegend, die ich nicht kenn, bzw wo ich keine Ahnung hab was ich eingestellt habe

Das Raid wird jetzt vermutlich eh komplett gekillt und auf ne AES Verschlüsselung umgestellt. Von dem her kann ich alle Parameter auf das Optimum setzen (wenn mir einer erklärt, wie ich die für meinen Anwendungszweck rausfinde).

Es wird ein Raid5 mit nem ext4 FS das sequentielle zugriffe so schnell wie möglich abarbeiten soll.

 

[Ernst@at]

Das geht recht einfach (wenn man weiß, wie )

• Partition muss auf jeder Memberplatte an 1MB-Grenze aligned sein
• (abhängig vom Verschlüsselungssystem, bei Truecrypt beginnt die innenliegende verschlüsselte Partition bei Offset +128K, soweit ich das behirnt habe) daher muss die Chunksize 1/4 davon sein
• Stripe(Chunk)size festlegen auf 32K (bei TC encrypt)
• bei 5 Platten im RAID5 muss für optimale Lese- und Schreibperformance die Clustersize des Filesystemes dann 4xChunksize =128K (bei TC encrypt) sein
• dieser Wert der Clustersize ist bei der ext4-Erstellung per mkfs -C option einzustellen

Voraussetzung für optimale seq. Performance ist natürlich, dass die Applikation auch die Daten in der Größe der Clustersize schreibt, nur so ist gewährleistet, dass jeder I/O auf alle 4 Stripes eines Stripesets aufgeteilt und das Paritystripe direkt daraus errechnet werden kann, und daher vor dem Schreiben nicht gelesen werden muss.