ki kéne cserélnem a raid-et valami gyorsabbra... :S

az utóbbi időben sok vinyót kellett turkásznom, pár évestől a viszonylag új szerkezetekig, és közben le is mértem a sebességüket...
és hát meg kellett állapítanom, hogy bizony a modern vinyók meglepően gyorsak.

sokszor egy sima vinyó hozta azt a sebességet, amit otthon a régi raid-em hoz. persze az két 80-as, 7200rpm-es. 2mb cache, sata2 vinyó, azokon még nem voltak ilyen adatsűrűségek, mint egy mostani vinyón - gondolom ez is az egyik ok.

szóval eléggé outdated az otthoni megoldás, ráférne egy kis vérfrissítés...

lehet, kicserélem a vinyókat valami gyorsabbra.

csak hát itt jönnek az érdekes dolgok. mostani összesen 160-as kapacitású tömböt könnyen backupolom, mert kicsi és nem sok minden van rajta. de ha lecserélem, akkor minimum 2x320-as vinyót kell vegyek, vagy inkább 500-asokat, azok az igazán gyorsak... akkor lesz 640gb vagy 1tb tömböm, na azt hová a fenébe mentsem le?

meg aztán ez a két kis vinyóm ez tök hangtalan és hűvös. az újak meg nem lesznek ilyen halkak. ez is fontos szempont nekem.

meg eléggé bonyolult lesz a mostani raid-ről átrakni a rendszert az újra, mivel enyi vinyó már nem fér bele a gépbe egyszerre, úgyhogy két lépcsőben kell csináljam egy köztes vinyóra tárolva az image-et.

és mindezt linux alól, ahol messze nem vagyok eléggé magabiztos :)

a terv: mostani tömbről dmraid-del és dd-vel mentek egy fájlt a rendszerpartícióról. a többi partícióról csak a fájlokat másolom le. eztán raid kiszerel, új vinyók beszerel. új raid létrehozása a biosban. eztán új rendszerpartíció létrehozása. image fájl visszamásolása dd-vel és dmraid-del. grubot rája, eztán reboot, további partíciók létrehozása, majd fájlok visszamásolása.

kérdés, hogy dmraid-ről dd-vel készített backup, illetve visszaállítása tökéletes megoldás-e? sosem használtam még dd-t dmraid-en. egyáltalán lehet?

na és milyen vinyót? van egy fölös 320-as wd3200aaks, 7200rpm, 16mb cache, sata2. ilyet még tán lehet is kapni és olcsó is. ebből elég lenne egy újat venni, mivel már van egy. de ez nem az az eszetlen gyors vinyó, és nem is csendes... ha ebből csinálok új raid-et, az nem lesz látványosan gyorsabb. (ezek tudnak mondjuk 70mb/s-t átlagban olvasni/írni, a kis 80-asok meg 60-at, szóval nem nagy különbség...) olyat kéne venni, ami tud egy 100mb/s-t legalább. na az már valami lenne. utóbbi tesztjeim azt mutatták, hogy egy 500-as vagy nagyobb vinyó az ennyit tud átlagban, de ekkora vinyók feleslegesen nagy tömböt adnának és persze nem is olcsók.

valaki hirdetett itt 2db ocz core ssd-t, 64gb-st, nagyon olcsón. na azt rögtön venném is meg, de már megelőztek. két olyat berakni raid-be, és csak úgy pörögne! :)

nem is tudom, érdemes-e egyáltalán nekifognom...? valószínűleg elpiszmognék vele egy hétvégét, és nem is biztos, hogy sikerülne, és hogy egyáltalán hozna-e jelentős sebességnövekedést? ha kiveszem a régi vinyókat a gépből, és az újakra létrehozok a biosban egy tömböt, és neadjisten nem sikerül visszarakni rá a rendszert, akkor ennyi volt. a régi vinyókat már hiába rakom vissza, mert akkor újra létre kell hoznom a tömböt, és az kapásból adatvesztéssel jár. szóval egy lövésem van, ha az nem sikerül, akkor bukta.

na még alszok rá egyet szerintem.

( LGee | 2009. 02. 27., p – 16:42 )

lvm mirror? (meg csak tervezem kiprobalni linuxon, de aix-en teljesen jol mukodik)

te csak hallgass, te galád, és örülj az új ocz ssd-dnek! :D :D :D majd légyszi számolj már be, hogy hogy megy a cucc, mert szépek ezek a számok, de a real life performance az ugye egy más dolog... mert én is ilyesmiket akartam venni, mondjuk a core v2-t néztem ki, de az szerintem csak bugfix verzió :)

ja hát aix-en jól megy az lvm, az már más kérdés, hogy nekem teljesen felesleges itthonra.

ja és hát azt nem írtam, hogy ez a rendszer, amiről szó van, ez egy win xp. (a zubuntu egy másik diszken van) és mivel még nem találtam olyan "klónozó" programot, ami "offline" módban (mivel windows-t "klónozni" futó rendszer alól nem túl szerencséss tudtommal :) ), ezért gondolkozom linux alóli megoldáson. a dmraid már be van konfigurálva, megy is faszán, de ilyen teljes dd-mentést még nem próbáltam vele.

--------------------------------
feel the beat - it's everywhere!

Felejtős - a Linuxos és az AIX-es LVM megvalósítás teljesen másként néz ki, és linuxon egyáltalán nem nevezném se stabilnak, se jónak ( főként nem ha a sebesség a cél, és pláne nem ha ne adj isten még egy RAID tömb fölé akarja rakni az ember, mert akkor az katasztrófa sebességre nézve)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nalunk nem katasztrofa raid felett. Mondjuk a lvm snapshot-ot nem szereti egyik szerveren, de mindegyik masikon tokeletesen uzemel, oracle szerver reakcioja gyors. Pedig az tudja porgetni a winyot, ha arrol van szo...
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Prószáld meg a dinamikus méret növelést/csökkentést aktív FS alatt ( ha már az AIX-el hasonlítjuk össze (bár félig jogos, hogy a csökkentés ott is csak 5.3 alatt megy minimum és JFS2 esetén)), avagy egy sebesség tesztet adott gépen belül RAID+LVM párossal, illetve sima RAID-el, majd csak simán LVM-el, illetve normál rendszerek esetén..
A saját tapasztalataim, hogy sima esetén a vinyók hozzák az elvárt szintet, RAID esetén a RAID-től elvárható teljesítmény jön kb ( persze itt most függ, hogy milyen RAID tömböt kreálsz.. Én az ismertebbeket néztem: 0,1,5, ott ez volt a tapasztalat ). Amennyiben sima LVM-et használsz (lvm2 persze) csak, úgy 1-2 RAID funkciót helyettesíteni lehet ( ~mirroring ), meg az adott LVM funkciók is jól jönnek ( XFS alatt kifejezetten, bár néha ott is rakoncátlankodik ).. De ha összekombináltam a RAID tömböt és az LVM-et, az nálam a performanciára katasztrofálisan hatott..
Az mondjuk tény, hogy csak egy disztró alatt próbáltam ( debian ), de ott moduláris, illetve kernelbe paszírozott driverrel is; azt meg nem hinném, hogy az lvm2 csomag akkora különbségeket hozna ki OS és OS között..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem tudom, nalunk amugy sem lehet online kotetet novelni, mert a ext3-at mindenkepp utana kell igazitani, azt meg mountolt allapotba asszem nem lehet megoldani. Ha valami folyamatosan irja-olvassa akkor meg plane. De ez nem is uzemszeru dolog, hanem tervezett leallas kereteben valositjuk meg. Csokkentes meg nem volt szukseges.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Akkor viszont elárulhatnád, hogy az LVM-nek melyik funkcióját használjátok ki, mert szerintem pont hogy ez az egyik leghasznosabb funkciója.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Várj egy picit... Én személy szerint azért tettem fel a kérdést, mert nálunk az LVM-ek növeléséhez nem kell semmiféle szolgáltatás kiesés, mivel online elvégezhető művelet ( Linux alatt is, bár ahhoz nem ext3 kell az tény ), így üzemszerűen megvalósítható tevékenység is.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nalunk meg sajnos "policy", hogy csak ext3-at hasznalunk, de kulonben sem tudom, hogy pl. egy Oracle szerver vagy hasonlo mennyire toleralja az ilyesmit.

De amugy is, ez egy bank, itt akkor is sokkal eroteljesebb policy-k vannak, ha egy sima ssh kapcsolat kiepiteserol van szo, most gondold el mi lehet bonyibb esetben.

Kulonben ott, ahol uzemszeruen kell winyomeretet allitgatni (vagyis az normalis, hogy napi-heti szinten kell ezt birizgalni) ott enszerintem nagyobb problemak is vannak, ugyanis ez igy hibas tervezes. Illik tudni, hogy egy adott szolgaltatasnak mekkora a novekedesi rataja, es aszerint foglalni diszket neki. De persze en csak egy Linux admin vagyok...
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Oracle-vel nincs tapasztalatom, de DB2 egész jól tolerálja még RAW kötetek mellett is..

"Kulonben ott, ahol uzemszeruen kell winyomeretet allitgatni (vagyis az normalis, hogy napi-heti szinten kell ezt birizgalni) ott enszerintem nagyobb problemak is vannak, ugyanis ez igy hibas tervezes."

Én is így gondolom.. tényleg ki kéne tiltanunk az összes usert aki használja ezeket a köteteket :))

"Illik tudni, hogy egy adott szolgaltatasnak mekkora a novekedesi rataja, es aszerint foglalni diszket neki. "

Ez nálunk nem egészen így van - úgy megy, hogy a customer fizet, hogy ezt meg ezt kapja.. Ha ő azt akarja, hogy a tegnapi 3 TB holnaptól 4 legyen, akkor abból bizony 4et kell csinálni.. Az csak külön hab a tortán, hogy ezt simán megcsináljuk bármiféle kiesés nélkül neki, szal ő is happy, meg mi is..

De amúgy még mindig nem válaszoltál arra a kérdésemre, hogy az LVM-et akkor ti mire használjátok?? Csak hogy 1 nagy kötetet láthassatok, ami elfekszik több diszken??

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A customernek altaban az ember inkabb soft/hard quotat emelget, ez ugyanis a kotet meretenek birizgalasat nem igenyli, sokkal dinamikusabban es egyszerubben megvalosithato, mintha allandoan kotetet kellene novelgetni.

A LVM nalunk fokepp azert kerult bevezetesre, hogy a diszkrendszer dinamikusan bovitheto legyen, amennyiben erre szukseg van, ne kelljen 2-3-500 GB-okat masolgatni amikor a bovites elkerulhetetlenne valik. Bedobjuk a plusz diszk(ek)et, megkapjak az esetelges RAID-et, majd roppennek be az LVM ala physical volume-nak es megkapja az eppen erintett vg.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"A customernek altaban az ember inkabb soft/hard quotat emelget, ez ugyanis a kotet meretenek birizgalasat nem igenyli, sokkal dinamikusabban es egyszerubben megvalosithato, mintha allandoan kotetet kellene novelgetni."

Ezzel azért vitatkoznék, tekintve, hogy a kötetet 1 parancsal tudom növelni és csökkenteni is full biztonságosan. Bármiféle LDAP, vagy hasonló alapokon nyugvó quota rendszerrel ellentétben.

szerk: Na mind1.. részemről zároltam a témát, mert 2 full különböző rendszert próbálunk meg összemérni..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

nem csak rendszernek. de az is ráfér majd bőven. igazából zenéléshez kéne, főleg egy multitrack szekvencer zabálja meg a vinyót, több sávon több 50-100-200 megás wav fájllal dolgozik egyszerre, és mivel élőben megy az egész, fontos, hogy a lehető leggyorsabban tudja beolvasni a wav-okat. (illetve írja és konvertálja is őket közben) 3-4 párhuzamos olvasás még biztonsággal elmegy a mostani lassúcska tömbről is, de már azért érezhetően lassú így. annak meg nem kéne előfordulni, hogy egyszer csak (élőben) elhallgat a zene, mert a lemezek nem tudják eléggé gyorsan tolni neki az adatot :)
szóval a rendszer lenne rajta (xp), egy 20-30 gigás partíción, egy partíción a zenék, hangminták, sound bank-ek, amikből a wav-ok készülnek (szintén on the fly), és egy "temp" partíció, amire a program a wav fájljait generálja és onnan olvassa be őket menet közben.
igazából a sebesség miatt most azt csinálom, hogy a zenék egy külön lemezen vannak, és csak a "temp" van a tömbön, így az írás/olvasás nem ugyanazon a lemezen megy egymást kiütve, hanem két lemezről párhuzamosan, ebből ugye az írás, ami a jelentősebb, ez van a gyorsabb raid-tömbön. (természetesen raid 0-ról van szó)
a temp-be a wavokat úgy kell elképzelnmi, hogy egyszer hozza őket létre, és utána már csak olvassa őket. tehát ez nem olyan folyton írt temp igazából, nem fogja kinyírni az ssd-t, ettől nem kell tartani.
ami viszont érdekes kérdés az ssd-nél, hogy ugye kis fájlok, kis blokkok írása/olvasása az mlc csipes ssd-knél (de asszem még az slc-nél is) tetű lassú. a program viszont inkrementálisan generálja a wav fájlokat. ezt onnan tudom, hogy ha párhuzamosan csinálok vele több wav-ot, akkor iszonyúan töredeznek a fájlok. tehát a program egyszerre mindig csak kis adagokat ír a lemezre. kérdés, hogy akkor ebben az esetben vajon lassú lesz?

--------------------------------
feel the beat - it's everywhere!

( bsh | 2009. 02. 28., szo – 10:41 )

jó, a dd működik, kipróbáltam :) i love linux! :)

amúgy a 80g-s vinyó önmagában ezt hozza:

raw olvasás: dd if=/dev/sdb of=/dev/null bs=8192 count=1M
1048576+0 beolvasott rekord
1048576+0 kiírt rekord
8589934592 bájt (8,6 GB) másolva, 120,657 mp, 71,2 MB/mp

raid0-ban kettő meg ezt:

raw olvasás: dd if=/dev/mapper/nvidia_bhaebgaj1 of=/dev/null bs=8192 count=1M
1048576+0 beolvasott rekord
1048576+0 kiírt rekord
8589934592 bájt (8,6 GB) másolva, 60,2601 mp, 143 MB/mp

ntfs-3g olvasás: dd if=/media/raid0/BSH_PART_C/pagefile.sys of=/dev/null bs=8192
262144+0 beolvasott rekord
262144+0 kiírt rekord
2147483648 bájt (2,1 GB) másolva, 21,1282 mp, 102 MB/mp

ntfs-3g írás: dd if=/dev/zero of=/media/raid0/BSH_PART_C/testfile.dat bs=8192 count=256k
262144+0 beolvasott rekord
262144+0 kiírt rekord
2147483648 bájt (2,1 GB) másolva, 38,7819 mp, 55,4 MB/mp

a 320-as wd meg ezt:

raw olvasás: dd if=/dev/sdc1 of=/dev/null bs=8192 count=1M
1048576+0 beolvasott rekord
1048576+0 kiírt rekord
8589934592 bájt (8,6 GB) másolva, 106,128 mp, 80,9 MB/mp

ntfs-3g olvasás: dd if=/media/BSH_WDC_1/pagefile.sys of=/dev/null bs=8192
262144+0 beolvasott rekord
262144+0 kiírt rekord
2147483648 bájt (2,1 GB) másolva, 30,4502 mp, 70,5 MB/mp

ntfs-3g írás: dd if=/dev/zero of=/media/BSH_WDC_1/testfile.dat bs=8192 count=256k
262144+0 beolvasott rekord
262144+0 kiírt rekord
2147483648 bájt (2,1 GB) másolva, 60,9337 mp, 35,2 MB/mp

--------------------------------
feel the beat - it's everywhere!

( bsh | 2009. 03. 05., cs – 22:40 )

jó, hát akkor ezt mégis meglépem :)
kezdetnek a 320-as wd helyére jött egy 500-as, holnap jön a másik 320-as wd, és akkor átrakom rájuk a rencertet.
na kíváncsi leszek, hogy dd-vel mit fog lépni :)

--------------------------------
feel the beat - it's everywhere!

( bsh | 2009. 03. 06., p – 18:49 )

na hát sikerült! :) nem volt egyszerű, már majdnem elkönyveltem az újratelepítést, de végül sikerült.
első körben lementettem a tömbről az első partíciót: 

dd if=/dev/mapper/nvidia_bhaebgaj1 of=/mnt/data/image.dat bs=4096

második körben kiszereltem a két régi vinyót és bekötöttem az újakat. a gépet bekapcsoltam, és a raid vezérlő biosban létrehoztam az új tömböt.
majd boot ismét ubuntuba. (nyilván, már csak az volt talpon :) )
harmadik körben gparted-del létrehoztam egy partíciót a tömbön. gondoltam, akkor a 20 gigás c:-ből legyen mindjárt 40 giga, úgyhogy egy 40g-s partíciót hoztam létre.
ezután gondolkoztam, hogy kell-e ezt formázni ntfs-re, de végül úgy döntöttem, hogy minek, majd a dd úgyis létrehoz mindent, csak az még egy 20 gigás FS lesz a 40 gigás meghajtón, de majd azt meggyógyítom utólag.
úgyhogy negyedik lépésben visszamásoltam a partíció tartalmát: 

dd if=/mnt/data/image.dat of=/dev/mapper/nvidia_bijeidde1 bs=4096

eztán reboot.
hát a gép csak pislogott, de nem bootolt.
na jó, akkor megint elő az ubuntut. akkor formázzuk le ntfs-re és úgy tegyük rá az adatokat.
hát megint semmi eredmény.
hmm. akkor biztos valami mbr hiányzik neki...
na, elő az xp telepítő lemezt. elindítottam, floppiról be a raid drivert, és az xp telepítővel hoztam létre a 40 gigás partíciót, amit gyorsformáztam. majd rámásolta a fájlokat és rebootolt.
na gondoltam, ezzel megvolna az mbr meg a tuti jó ntfs partíció, akkor ismét boot ubuntuba és ismét rámásoltam az adatokat a már jó partícióra.
na ezzel sikerült is megoldani a dolog nehezebbik részét: reboot után szépen betöltődött az xp, szeme sem rebbent! :)
gondoltam, hogy a fájlrendszerrel baj lesz, mert az még 20 gigáról szól, közben a partíció már 40 gigás. és tényleg: a sajátgép 20 gigás fájlrendszert jelentett, a lemezkezelő meg 40 gigásat.
gondoltam, majd a jó kis chkdsk az felfedezi a hibát és korrigál.
úgyhogy reboot és chkdsk.
hát szegény nem vett észre semmi gyanúsat.
hmmm
akkor ismét elő az ubuntu, gondoltam, átméretezem kicsit a partíciót és az majd helyrerakja.
ezzel sikerült is találnom egy hibát a gpartedben: mikor ntfsresize-t hívja meg, rossz command line-t ad át neki. a partíció neve helyett a teljes tömb nevét adja át. a tömb neve /dev/mapper/nvidia_bijeidde, míg azon az első partíció neve /dev/mapper/nvidia_bijeidde1
úgyhogy elő egy terminált és akkor csináljuk kézzel: 

ntfsresize -s 40G /dev/mapper/nvidia_bijeidde1

pikk-pakk, meg is csinálta szépen, hiba nélkül.
na ekkor ismét reboot. windows checkdiskkel indul, de ez normális, mert az ntfsresize automatikusan dirty-re kapcsolja a fájlrendszert, hogy a windows tutira ellenőrizze le újra.
checkdisk lefut, hiba semmi, windows betölt, minden remek és jó.
és főleg: azért szemmel láthatóan gyorsabb lett :) pedig nem fűztem hozzá sok reményt...

--------------------------------
feel the beat - it's everywhere!