Sloučení dvou svazků pod RAID5 na ICH8R

[jan555]

- RAID0 ... nabídlo mi to všechno volné místo (tzn nejen to, co zbývalo na přidaném disku, ale i to, co zbývá na již existující particii)

Tzn. pravděpodobně konvert se ztrátou dat.

- RAID1 ... prošlo to až do místa, kde to zařvalo na nesprávný počet fyzických disků
- RAID10 ... totéž

Je potřeba sudý počet disků (2 pro RAID1, 4 pro RAID10).

[Darth Maul]

Tzn. pravděpodobně konvert se ztrátou dat.

Je potřeba sudý počet disků (2 pro RAID1, 4 pro RAID10).

Jasně, vím - spíš jsem to myslel tak, že to Matrix na využití zbývajícího místa nabídl a pak teprve uprostřed realizace zařízl... když jsem kovertoval dvoudiskový RAID1 na třídiskový RAID5, přavod na RAID10 to vůbec ani nenabídlo, i když ta možnost existuje v případě správného počtu (4) disků...

[jan555]

Ony jsou ty intelské řadiče mezi integrovanými dobré - rychlé, s vyváženým výkonem a spolehlivé. Ale přetrvávajících debilit je u nich taky dost, tohle je jedna z nich. Doteď jsem nepochopil, proč se např. nedá v BIOSu řadiče udělat ze single-disku RAID1 bez ztráty dat, ale jsou tam i lepší lahůdky - při přechodu z ICH-7R na ICH-8R jsem zkusmo připojil disky, řadič je bez problémů poznal, natáhl si konfiguraci a choval se jako že je všechno v pořádku. Nebylo - disky byly dobře o 50% pomalejší než na předchozím řadiči ... Stejně tak vytvořit si RAID5 array, který na úrovni volume nabídne vytvoření jiného RAID levelu, je dost netradiční.

[Darth Maul]

Taxem objevil další problém - mám RAID5 ze 3 disků a chtěl bych ho rozšířit o 4. identický disk... myslel jsem, že ho ICH8R dokáže nějak sežrat a rozšířit RAID5 na 4 disky, ale zatím se o to snažím marně a jediné co mi to nabízí je udělat z nového disku automatický náhradní pro případ úmrtí jednoho z těch tří.

Jde to vůbec takhle rozšiřovat?

[monsoon]

Taxem objevil další problém - mám RAID5 ze 3 disků a chtěl bych ho rozšířit o 4. identický disk... myslel jsem, že ho ICH8R dokáže nějak sežrat a rozšířit RAID5 na 4 disky, ale zatím se o to snažím marně a jediné co mi to nabízí je udělat z nového disku automatický náhradní pro případ úmrtí jednoho z těch tří.

Jde to vůbec takhle rozšiřovat?

Lepsi radice to umi, softwarovy raid v linuxu to take umi, ale jestli ICH to netusim.

[Paolo]

Taxem objevil další problém - mám RAID5 ze 3 disků a chtěl bych ho rozšířit o 4. identický disk... myslel jsem, že ho ICH8R dokáže nějak sežrat a rozšířit RAID5 na 4 disky, ale zatím se o to snažím marně a jediné co mi to nabízí je udělat z nového disku automatický náhradní pro případ úmrtí jednoho z těch tří.

Jde to vůbec takhle rozšiřovat?

ICH to nezvládne, mám 6x 320GB po 2x 3ks v RAID5 a zkoušel jsem si s tím hrát. BIOS mě pro RAID5 dával default strip size 64kB.

jinak bych nesouhlasil s jan555 o velikosti stripu a IMHO je tomu přesně naopak - při zápisu je větší strip horší, protože se musí přečíst celý, pak přexorovat a celý uložit, kdežto při čtení se jen čte a pokud není pole v degraded režimu, tak se čtou jen data bez xorování.
Podle výkonu polí při kopírování velkého objemu dat (cca 40GB) se stripe 64 a 128, co jsem zkoušel (pod TotalCMD), jsem nakonec vybral 64kB, ale čtení (zápis na jiný, samostatný disk) bylo při 128kB rychlejší.

Nejhorší propadák v rychlosti je ale pod čistým DOSem v GHOSTu (v. 2003) tam to jede JEN cca 40MB za minutu!!! a je jedno jestli čtení nebo zápis, přičemž ze samostatného disku to valí na skoro 1GB/min. Zkoušel jsem i RAID1 a tam už takovýto propad nebyl, jelo to (při zápisu na RAID1) cca 800MB/min.

[Darth Maul]

ICH to nezvládne, mám 6x 320GB po 2x 3ks v RAID5 a zkoušel jsem si s tím hrát. BIOS mě pro RAID5 dával default strip size 64kB.

Nezvládne rozšíření na 4 disky ze 3, nebo neutáhne 4 disky v RAID5 jako takové?

[Paolo]

Nezvládne rozšíření na 4 disky ze 3, nebo neutáhne 4 disky v RAID5 jako takové?

V RAID5 jede i 6 disků, ale neumí rozšíření pole o další disk.
On RAID na ICHxR je celý takový zvláštní, protože funguje i jen na části disku a další část může být součástí jiného pole. Informace o tom, který disk je který a co v něm patří do jakého pole je pak uložen na konci disku (tři poslední sektory).

to jan555 -> jj, souhlasím s tebou, že na externím řadiči (sice mi jich neprošlo rukama desítky ale spíš jednotky ~10) se chová pole jinak - řek bych že za to může specializovaný HW (většinou i s nějakou vyrovnávací pamětí), který výpočty paritních bloků zvládá "levou zadní".
Jiank ten test nebyl o kopírování velkých souborů a o kopírování všech souborů ze tří adresářů na disku (cca 40GB) a průměrná velikost byla kolem 1MB. Zase sem neměl tolik času - musel jsem vrátit disky, na kterých jsem měl odložená data.

[jan555]

jinak bych nesouhlasil s jan555 o velikosti stripu a IMHO je tomu přesně naopak

Neříkám, že s tebou nesouhlasím, ale ani že souhlasím, můžu k tomu říct tak to, že jsem nevycházel ze svých zkušeností, ale ze sumáře rozsáhlých testů, které jsem našel na (pro mě) věrohodných webech. Konfiguroval a provozoval jsem mraky diskových polí od menších až po centra, ale všechno na pořádných řadičích. Na SATA jsem RAID5 nikdy neměl, takže se hádat nebudu - totiž nejen že rychlost, vlastnosti nebo možnosti on-board řadičů se radikálně liší od externích, ony se mezi sebou dost liší i různé srovnávací testy toho samého. Suma sumárum nemám a neznám žádný kvalitní podklad, na základě kterého bych mohl víc přispět do diskuze o stripe size na integrovaném Intelu, ty testy si může vygooglit a projít každý sám.

Každý řadič (nebo třída, platforma, apod.) má specifické vlastnosti i specifický výkon na různých nastaveních a co jsou osvědčené konfigurace u serverů, to mohou být jedny z nejhorších nastavení na desktopu. Nakonec má Intel s tím, co doporučuje, třeba docela pravdu ...

Jen jedinou poznámku - pokud volíš stripe size podle rychlosti při přenosu velkého balíku dat, máš na domácího uživatele dost nestandardní primární užití pole a taky kritérium výkonu. Je snad jasné, že už při random read operacích bude vztah stripe size a výkonu odlišný a to zajímá typického domácího uživatele víc (nemluvě o ještě méně typických domácích využitích, jakými jsou typicky DB operace, kde jsou nároky zase úplně jiné). Ta konkrétní konfigurace musí odpovídat využití, protože co je pro některé operace výhodou, je pro jiné nevýhodou. Bohužel, pokud si někdo není schopný na základě testů udělat jasný obrázek (což jsem já), musí si to odzkoušet - anebo možná pojede "na půl plynu" (obrazně).