PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : RAID: Stripesize ermitteln?


TeleTubby666
2010-11-22, 14:00:19
Hi,

aus irgendeinem Grund hat mein Promise Fasttrack Controller die Einstellungen über mein RAID10 über Nacht vergessen - das Array erscheint einfach nicht mehr. :hmm:

Ich würde das RAID jetzt wieder neu arrangieren, ohne die Festplatten zu initialisieren, formatieren oder in sonst irgendeiner Art und Weise zu verändern.

Jetzt weiß ich aber leider nicht mehr, welche Stripesize (32 oder 64kb) ich damals eingestellt hatte. Ich fürchte nun, dass es zu Datenverlust kommen wird, wenn ich die falsche angebe, daher muss ich die richtige heraus bekommen.

Bitte dringendst um Hilfe!

Danke!

FeuerHoden
2010-11-25, 12:28:58
Ähm, ich glaube mal gelesen zu haben dass Dateien welche kleiner als ein Stripe sind sich ohne Controller über eine grobe Datenwiederherstellung retten lassen.
Wenn du eine Datenwiederherstellungssoftware hast bei der man einstellen kann nur Dateien zwischen 12-24k und 65k wiederherzustellen, dann kannst du das mal ein paar Minuten laufen lassen und dann schauen ob nur die Files bis 24k lesbar sind oder auch die größeren. Sind nur die kleinen Dateien lesbar hast du ein 32k Stripseit, gehen die größeren auch dann wird es ein 64k Stripeset sein.

Das war ein Beitrag hier im Forum, aber ich finde ihn nicht wieder.

Birdman
2010-11-25, 20:16:46
Wenn die Datei über zwei Stripesets verteilt wird, bringts auch nix wenn diese an sich kleiner ist als die Stripesize - mit Recoverytools kannst dieses auch nicht mehr recovern.

Grundsätzlich gilt, je kleiner die Stripesize desto besser die I/O Performance und die grössere die Stripesize, desto besser die Bandwidth.
Viel mehr Auswirkungen hats nicht und die Entscheidung dieser Grösse sollte man von der Applikation abhängig machen, welche auf dem Array dreht.

Btw. Hier ein Interessantes Doku von LSI, bzgl. diversesten Raidparametern und Disktypen: http://www.lsi.com/DistributionSystem/AssetDocument/Benchmark_Tips_Jan_2010_v2_0.pdf

Gast
2010-11-25, 20:44:38
Nur so eine Idee: Backup von jeder einzelnen Platte machen und jede Stripesize testen, mit der Default-Stripe-Size anfangen ...

FeuerHoden
2010-11-26, 14:44:48
Birdman,

es soll angeblich tatsächlich so sein das Dateien die kleiner als ein Stripe sind, NICHT auf mehr als eine Platte verteilt werden, das kann natürlich je nach Controller unterschiedlich sein, aber so habe ich es gelesen.

sun-man
2010-11-29, 10:58:47
Er hat auch woanders gefragt - aber es kam nie wieder eine Antwort.

Birdman
2010-12-04, 14:13:35
Birdman,

es soll angeblich tatsächlich so sein das Dateien die kleiner als ein Stripe sind, NICHT auf mehr als eine Platte verteilt werden, das kann natürlich je nach Controller unterschiedlich sein, aber so habe ich es gelesen.
Da hast du aber dicken Bullshit gelesen, denn dies ist technisch NICHT möglich.

Nehmen wir an wir haben 4 Disks @1GB im Raid0 mit einer Stripesize von 1MB.
Das Array erreicht damit eine Grösse von 4GB.
Nun schreiben wir 4000 mal eine 750kB grosse Datei.
Jetzt möchtest Du eine 500kB grosse Datei schreiben und gemäss deiner Theorie ginge das aber gar nicht da der Controller dies nicht zulässt.
Oh mey, das würde aber einen netten Bluescreen unter Windows auslösen....

Es macht auch gar keinen Sinn, auf Controller-Ebene solche arbiträren Grenzen für das Speichern von Daten einzuführen.
Nicht zu vergessen dass damit ein Controller eine komplette Block Mapping Tabelle über das ganze Array irgendwo speichern müsste.
Denn ein OS/Filesystem kennt die Stripesizes und Grenzen nicht und sagt lediglich "speichere diese datei mit 1MB in Block 102-197"
Wenn diese Blöcke nun auf einer Disk nicht ganz genau fortlaufend sind, dann muss der Controller sich dies irgendwo speichern, wie es z.B. SSD machen.

Ein Raidcontroller kann dies aber nicht, denn der hat ja keinen Speicher für sowas und zudem müsste der RIESIG sein, denn er müsste ja für die maximale Grösse eines Arrays taugen, also auch für Fälle wo jemand an jeden Port einen 2TB oder heutzutage 3TB Disk hängt.
Da viele Controller heutzutage auch Expander unterstützen und somit oftmals bis zu 128! Disks, so müsste dieser Speicher für das Blockmapping enorm gross sein.

FeuerHoden
2010-12-05, 23:21:57
Hast du einen Link dazu?

Ich hab nicht gesschrieben das ein Stripe nur mit jeweils einer Datei beschrieben sein kann oder das eine Datei nicht mehrere Stripes auf der selben Platte belegen kann.

Was macht ein Controller wenn ich 16 4kb Dateien auf einem Raid0 aus 2 Platten mit einer Stripesize von 32kb speichern will? Für den Controller wäre es weniger aufwändig jeweils 8 Dateien pro Stripe zu speichern. Bei solch kleinen Dateien merkt man den langsameren Zugriff ja so oder so nicht also wärs egal.

Mir ist es auch egal, ich habs so gelesen und jetzt hab ich deins auch gelesen. Man könnte es ja überprüfen aber ich werde bestimmt keines meiner Raids zerlegen um nachzusehen :D

DerRob
2010-12-07, 01:35:22
Birdman,

es soll angeblich tatsächlich so sein das Dateien die kleiner als ein Stripe sind, NICHT auf mehr als eine Platte verteilt werden, das kann natürlich je nach Controller unterschiedlich sein, aber so habe ich es gelesen.
Da hast du aber dicken Bullshit gelesen, denn dies ist technisch NICHT möglich.
Natürlich können Dateien, die kleiner als ein Stripe sind, auch mal auf nur einer Disk gespeichert, je nach Größe der Datei und des Stripes passiert das sogar recht häufig.

Nehmen wir an wir haben 4 Disks @1GB im Raid0 mit einer Stripesize von 1MB.
Das Array erreicht damit eine Grösse von 4GB.
Nun schreiben wir 4000 mal eine 750kB grosse Datei.
Jetzt möchtest Du eine 500kB grosse Datei schreiben und gemäss deiner Theorie ginge das aber gar nicht da der Controller dies nicht zulässt.
Oh mey, das würde aber einen netten Bluescreen unter Windows auslösen....
Würde es nicht, da eine Datei einen Stripe nicht komplett belegt, sondern da immer noch etwas Platz frei ist.
Nehmen wir mal dein Beispiel, Stripe-Size 1MB, Dateigröße 750kB.
Datei 1 landet komplett auf Disk 1 im ersten Stripe. 750kB belegt, 250kB noch frei.
Von Datei 2 landen 250kB ebenfalls in Stripe 1, die restlichen 500kB landen in Stripe 2 (auf Disk 2). Stripe 1 voll, Stripe 2 500kB frei.
Von Datei 3 landen 500kB in Stripe 2 (auf Disk 2), 250kB in Stripe 3 (auf Disk 3).
Datei 4 landet wiederum komplett in den restlichen 750kB von Stripe 3/Disk 3.
Usw., usf.
Teilweise landen die Dateien komplett auf nur einer Disk, teilweise werden sie auf 2 Disks verteilt. Wenn du das ganze jetzt aber nochmal mit 75kB großen Dateien durchrechnest, wirst du sehen, daß der überwiegende Teil der Dateien nur auf einer Disk landen wird.

Nicht zu vergessen dass damit ein Controller eine komplette Block Mapping Tabelle über das ganze Array irgendwo speichern müsste.
Denn ein OS/Filesystem kennt die Stripesizes und Grenzen nicht und sagt lediglich "speichere diese datei mit 1MB in Block 102-197"
Wenn diese Blöcke nun auf einer Disk nicht ganz genau fortlaufend sind, dann muss der Controller sich dies irgendwo speichern, wie es z.B. SSD machen.
Der Controller braucht dazu garkeine große Tabelle, eine einfache kleine Formel reicht dafür vollkommen aus. Die Stripesize bleibt ja nach dem Erstellen des Raids immer gleich groß und ändert sich mittendrin nicht einfach.
Nehmen wir an, ich habe 4 Disks und die Stripesize ist 8 Blöcke groß. Dann sind Block 0-7 auf Disk 1, 8-15 auf Disk 2, 16-23 auf Disk 3, 24-31 auf Disk 4, 32-39 wieder auf Disk 1, usw.
Wenn dein OS jetzt deine Datei in Block 102 speichern möchte, muss der Controller nur kurz umrechnen, auf welche physikalische Disk der Block gehört.
Z.B. so (ich hoffe, ich verrechne mich jetzt nicht :freak:):

102 / 32 = 3, Rest 6 (der wievielte Stripe ist es auf der Disk?)
6 / 8 = 0, Rest 6 (welche Disk ist es (0 = 1. Disk), und der wievielte Block in dem Stripe ist es?)
Disk = 1, Block = 3 * 8 + 6 = 30

Der 197. Block wäre demzufolge dann ebenfalls auf Disk 1, Block 53. Der 12345678. Block wäre auf Disk 2, Block 3086422.
Für den Controller ist das also nur eine simpelste Rechenaufgabe.

Birdman
2010-12-07, 20:24:15
@Rob

?!?!?

Das ist doch genau das was ich sagen will - der Controller reiht schön aneinander und teilt auch kleine Dateien auf mehrere Stripes auf.
Und dank dem schönen aneinanderreihen weiss er auch in welchen Blöcken was gespeichert ist. (was eben nicht der Fall wäre, wenn der Controller die Daten "stripeoptimiert" abspeichern würde)

DerRob
2010-12-07, 20:55:37
Das ist doch genau das was ich sagen will - der Controller reiht schön aneinander und teilt auch kleine Dateien auf mehrere Stripes auf.
Nein, das macht er ja eben nicht. Wenn die Datei kleiner als die Stripesize ist, landet sie nur auf mehreren Disks (genauer gesagt 2 Disks), wenn sie "am Rand" eines Stripes liegt, und nicht mehr vollständig "reinpasst".

Kleine Dateien werden nicht "zerteilt", um sie auf mehrere Stripes aufzuteilen, sondern sie werden einfach hintereinander weg geschrieben. Je nach Größe der Datei landen sie auf einer, zwei, drei oder aus wie vielen Platten auch das Raid besteht. Aber je kleiner die Datei im Verhältnis zur Stripe-Größe ist, desto wahrscheinlicher ist es, daß sie nur auf einer Disk landet. Soll die Datei gleichmäßig auf alle Platten verteilt werden, muss sie mindestens StripeSize * Anzahl-der-Platten groß sein.

Ich hoffe, dieses Beispiel ist einigermaßen anschaulich:
Blöcke
-------------------------------------------------------
Disks: 111122223333444411112222333344441111222233334444
Files: aaaaaaabbbccccccccccccddeefggghhhhhhhhhhhhhhhhhh

Birdman
2010-12-10, 20:40:00
als hätte ich je was anderes geschrieben......

Es wird weder absichtlich zerteilt, noch wird eine Datei die kleiner als ein Stripe ist, extra so plaziert dass sie in einen ganzen Stripe passt.
Sie Stripes sind für das schreiben der Daten vom OS/Filesystem aus komplett transparent.

FeuerHoden
2010-12-10, 23:20:22
Dann kann es also doch sein das Dateien die kleiner als ein Stripe sind nur auf eine Platte geschrieben werden. Oben sagst du aber 'Bullshit' dazu.

sun-man
2010-12-10, 23:39:21
Ihr vergesst IMHO die Chunk Sizes. Ich bleib mal bei Wiki.
Chunks sind Untereinheiten eines Stripe-Set, die Chunk Size bezeichnet die Größe eines solchen Chunks, also maximale Anzahl von Sektoren die zusammenhängend und sequentiell auf einer Platte angeordnet sind. Alle Blöcke oder Sektoren eines Chunks liegen auf der gleichen Platte. Ist das Ende eines Chuks erreicht, liegt der nächste sequentielle Datenblock auf einer folgenden Platte. Ein Stripe-Set setzt sich aus je einem Chunk pro Datenträger eines RAID-Verbunds zusammen. So besitzt beispielsweise ein aus vier Festplatten bestehendes RAID-0-Array mit einer Chunk Size von 256 KiB eine Stripe Size von 1 MiB. Unabhängig davon wird beim Formatieren eines Arrays die File System Block Size für das jeweilige Dateisystem gesetzt. Die Performanceauswirkungen der eingestellten Chunk Size[12] im Verhältnis zu der gewählten File System Block Size sind komplex.

DerRob
2010-12-11, 00:36:50
Ihr vergesst IMHO die Chunk Sizes. Ich bleib mal bei Wiki.
Das kann aber nicht passen, oder da werden andere/"falsche" Begriffe verwendet.
Bei allen Raid-Controllern, die ich bisher gesehen/gehabt habe, hat man die Stripe-Size eingestellt, von einer Chunk-Size habe ich nie was gesehen. Angenommen, ich stelle eine Stripe-Size von 1 MB ein und habe 4 Platten im Verbund, dann soll die Chunk-Size 256 kB sein. Ok, das ist ja noch verständlich, je 256 kB wandern auf eine Platte, bevor es weiter zur nächsten Platte geht. Aber was ist, wenn mein Verbund nur aus 3 Platten besteht, und ich eine Stripe-Size von 1 MB einstelle? Dann muss diese Chunk-Size ja 341,3 kB bzw. 349.525 und 1/3 Byte groß sein.Wie speichert man 1/3 Byte ab...?

sun-man
2010-12-11, 08:18:27
Zum Chunk muß man sich schon etwas besser informieren (ist jetzt nicht persönlich gemeint). Ich hab damit auch nicht so irre viel zu tun. Raid nutze ich nur @work mit meinen HDS Storages und dort haben die div. Vorgaben auf die wir bei nem 7+1 keinen Einfluss haben. Wir sehen auch zu das unserer Datenbanken ihre Datenblöcke so wegschreiben das ein Block einen ganzen Stripe füllt und nicht unnötig neu angesetzt werden muß.