Sziasztok,
2 db 2 TB-os merevlemezt szeretnék összefűzni RAID0-ba linuxos software RAID-del. Az lenne a kérdésem, hogy mekkora az optimális chunk méret.
HDD-k: 2*2TB SATA2
OS: Ubuntu 10.04 64bit
Fájlrendszer (stride-size és stripe-width természetesen meg lesz adva):
- ext4, 4 kB-os block méret ("/" mindenestől)
- ext4, 16kB-os block méret (nagy fájloknak)
Másik kérdésem, hogy a /boot lehet-e RAID0-n.
(Tisztában vagyok azzal, hogy RAID0 esetén nagy a kockázata az adatvesztésnek.)
A válaszokat előre is köszönöm!
- 1539 megtekintés
Hozzászólások
Miért szeretnéd a /boot-ot Raid0-ra, gondolom nem a hely miatt, hiszen ez egy néhány MB-os terület?!
- A hozzászóláshoz be kell jelentkezni
Ha nem muszáj, akkor nem szeretném a /boot-ot külön particióra tenni.
- A hozzászóláshoz be kell jelentkezni
Szerintem se a lilo se a grub nem tudja megoldani. A lilo a diszkről a fizikai címekről olvassa be a kernelt, így max. mirrorról tud tölteni. A grub ugyan ismeri a fájlrendszert, de az akkor még nincs - illetve van, de darabokban :) - ezért azzal se nagyon tud mit kezdeni. Így legalább a /boot-ot külön kell tenni, de - bár ezt se próbáltam - ez akár lehet egy usb pendrive-on is.
- A hozzászóláshoz be kell jelentkezni
Ez igaz.
Ezt most találtam: https://help.ubuntu.com/community/Installation/SoftwareRAID
Warning: the /boot filesystem cannot use any softRAID level other than 1 with the stock Ubuntu bootloader. If you want to use some other RAID level for most things, you'll need to create separate partitions and make a RAID1 device for /boot.
Az viszont továbbra is kérdés számomra, hogy chunk méretnek mit érdemes megadni.
- A hozzászóláshoz be kell jelentkezni
Volt 1-2 időszak, amikor foglalkoztam ilyen RAID dolgokkal. Akkor azt olvastam, hogy a nagyobb chunk méret nagyobb teljesítményt eredményez. Érdekes, mi? Akár azt is gondolhatnánk, hogy minél kisebb a chunk, annál nagyobb lesz a teljesítnény, mert akkor már a kis egybefüggő adatok beolvasásakor is érvényesül a párhuzamosság, de azt mondják, a sok fejmozgatás lerontaná az időt. Mindezek ellenére nagy chunk méret esetén is jól érvényesül a párhuzamosság (mármint az, hogy egy időben egyszerre több vinyó olvas/ír), hiszen egyszerre több processz/szál használja a tömböt, és minden processz több fájllal dolgozik.
Tehát, ha viszonylag nagy a chunk méret. akkor:
-Nagyobb az esélye, hogy egy adott fájl nincs több vinyóra széttörtdelve, tehát nem kell túl sok fejmozgatás a beolvasásához/kiíírásához.
-Mivel a tömbön egyidőben több művelet zajlik, mégis jól kijön a párhuzamos I/O műveletek előnye.
Azt hiszem, a 64kB chunk méret általánosnak mondható, bár én dolgoztam már 512kB-ossal is. Azt ne felejtsd el, hogy a partíciók határa chunk-határra essenek (valahol azt olvastam, hogy partícionálás helyett RAID tömbre használjunk LVM-et, az mindent 4MB-os határokra rendez), és a formázásnál is vedd figyelembe a chunk méretet! Ezen felül érdemes a blokkeszközök paramétereit buherálni a kernelben, nekem pl. a deadline scheduler (pl. `echo deadline > /sys/block/sda/queue/scheduler`) bejött. De ugyanott érdemes más paramétereket is cuccolgatni
- A hozzászóláshoz be kell jelentkezni
Ubuntu live CD-n lévő Disk Utility 512 kB-ot ajánl fel, úgyhogy úgy néz ki, azt fogom használni.
Természetesen nem felejtem beállítani a megfelelő paramétereket a fájlrendszer létrehozásakor. De az még odébb van, egyelőre még olyan dolgokkal szenvedek, hogy 2 TB-os HDD végén maradt 4 GB a Disk Utility szerint nem létezik, ezért itt nem tudom létrehozni az utolsó raid tömböt, mdadm meg nem akar nevet adni a tömbnek.
- A hozzászóláshoz be kell jelentkezni
Akkor azt olvastam, hogy a nagyobb chunk méret nagyobb teljesítményt eredményez. Érdekes, mi? Akár azt is gondolhatnánk, hogy minél kisebb a chunk, annál nagyobb lesz a teljesítnény, mert akkor már a kis egybefüggő adatok beolvasásakor is érvényesül a párhuzamosság, de azt mondják, a sok fejmozgatás lerontaná az időt.
Juj, nem szeretek ilyeneket olvasni.
Kezdjük talán itt: http://people.redhat.com/msnitzer/snitzer_rhsummit_2009.pdf
Az előadás vége fele vannak idevonatkozó ökölszabályok, de érdemes a többi részt is végigolvasni, hogy valami kép alakuljon ki, hogy kb mi is van emögött, milyen eszközökkel lehet mérni. De még ez is eléggé csak a felszínt kapargatja.
Elég sok szempont van, ami beleszólhat a stripe méret megválasztásába.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
Egyébként a saját elgondolásom is az volt, hogy egy szálon történő szekvenciális olvasáshoz jobb lehet a kis chunk méret. Igaz, ezt nem írtam le, de még ezt figyelembe véve sem látom azt, hogy olyan borzalmasan nagy hülyeséget írtam volna. Oder? Húzzakapi****ba?
- A hozzászóláshoz be kell jelentkezni
Nem borzalmasanhülyeség, csak az nem tetszett nekem, hogy a megfogalmazásod több ponton is úgy hangzott, mintha az áteresztőképességét kezelnéd kiemelten, abból is különösen a szekvenciális hozzáférést. Kétségtelen, hogy ezt a legkönnyebb mérni, de a valóságban a kis méretű, viszonylag elszórt hozzáféréseknek sokkal nagyobb a relevanciája, nem beszélve a válaszidőről, ezekre pedig nem egyszerű jó reprodukálható benchmarkot találni, mert rengeteg változó paramétered lehet. Kezdve azzal, hogy az alkalmazásod (és/vagy alatta fájlrendszered) milyen blokkméretet kezel egységként, milyen lokalitással dolgozik, írás és olvasás műveletek aránya milyen, mennyire burst-ös. Az utóbbiaknál alaposan bejátszik az IO ütemező is. A tapasztalat az, hogy többnyire a (fenti okfejtésednél akár bonyolultabb modellt is használva) analitikusan megbecsült eredmények is gyakran köszönőviszonyban nincsenek a tényleges mérési eredményekkel. Sajnos az a helyzet, hogy vagy konkrét alkalmazásra optimalizál az ember vagy próbál valami általános kompromisszumos beállítást keresni. A leírt megállapításaid nem hibásak, de messze nem a teljes képet mutatják. Egyébként no offense.
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
azert a grubra tennek egy kiserletet, a lucidos grub2 forrasaban van ilyen:
int level; /* RAID levels, only 0, 1 or 5 at the moment. */
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Köszönöm a tippet, de későn jött a hozzászólás. :)
/boot-nak már létrehoztam egy RAID1 tömböt.
- A hozzászóláshoz be kell jelentkezni
Én saccra azt mondom, hogy ennyi adata alapján nem lehet megmondani.
Ha űberbrutál IO-t kell kitolnod, akkor mindenképp tesztelned kell, hogy az adott alkalmazással, ami a diskeket terheli, mi az optimális beállítás. És ebben az esetben egyáltalán nem biztos, hogy a raid0 lesz a szűk keresztmetszet (szekvenciális olvasással tudnak ám tolni a "bolti" sata diskek is, csak legyen ami feldolgozza).
Ha meg csak azért kell, hogy gyors legyen (pl. otthoni fájlszerver), akkor kb. mindegy.
- A hozzászóláshoz be kell jelentkezni
hdparm -t csinálj mérést a raw device-on és az md-n is. én már tapasztaltam olyat is, hogy nem hozott gyorsulást a linux sw raid0, majd várom az eredményed.
- A hozzászóláshoz be kell jelentkezni
Köszönöm szépen mindenkinek a hozzászólást!
A következők történtek:
- grub2 nem ment fel sehogy, ha /boot RAID1-ben volt (biztos, hogy meg lehetne valahogy oldani, de a jelenlegi tudásommal ez szerintem napokba kerülne)
- csak "/" lett RAID0-ban a végén az Alternate telepítő alapértelmezett beállításaival (az alapértelmezett beállítások természetesen még véletlenül sem azonosak a Live CD-n lévő Disk Utility alapértelmezett beállításaival), minden más egyszerű partíció
--------------------------------------------------------------
Lemezek:
/dev/sda:
- /dev/sda1: 1 GB /boot - ext4
- /dev/sda2: 16 GB RAID0 - /dev/md0 1. része
- /dev/sda3: ~2 TB - ext4
- /dev/sda4: 4 GB swap
/dev/sdb:
- /dev/sdb1: 1 GB formázatlan terület
- /dev/sdb2: 16 GB RAID0 - dev/md0 2. része
- /dev/sdb3: ~2 TB - ext4
- /dev/sdb4: 4 GB swap
/dev/md0: 32 GB / - ext4
--------------------------------------------------------------
$ sudo mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Fri Jun 4 23:59:23 2010
Raid Level : raid0
Array Size : 31250304 (29.80 GiB 32.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Jun 4 23:59:23 2010
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Chunk Size : 64K
UUID : f706beac:451c7a95:dbf869ed:bf68f23e
Events : 0.1
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2
--------------------------------------------------------------
Tesztek - "dd":
/dev/md0 (bs=1GB count=10 , valamint conv=fdatasync írásnál):
- write: 207 MBps
- read: 213 MBps
/dev/sda3 és /dev/sdb3 (bs=1GB count=10, valamint conv=fdatasync írásnál):
- write: 108 MBps
- read: 112 MBps
--------------------------------------------------------------
Tesztek - "hdparm -t":
/dev/md0:
Timing buffered disk reads: 612 MB in 3.01 seconds = 203.52 MB/sec
/dev/sda3:
Timing buffered disk reads: 310 MB in 3.00 seconds = 103.27 MB/sec
/dev/sdb3:
Timing buffered disk reads: 326 MB in 3.01 seconds = 108.27 MB/sec
- A hozzászóláshoz be kell jelentkezni
Samsung HD103SJ és HD103UJ merevlemezek FakeRAID0-ban nálam. Chunk asszem 128KB, de megnézem majd, ha rebootolok.
ext3 - 1.8TB
/dev/mapper/isw_cigicbbhdd_stripe6:
Timing buffered disk reads: 660 MB in 3.00 seconds = 219.98 MB/sec
ext4 - "/" csatolási pont
/dev/mapper/isw_cigicbbhdd_stripe3:
Timing buffered disk reads: 610 MB in 3.00 seconds = 203.06 MB/sec
|| "Software is like sex: it's better when it's free." Linus Torvalds || Visit Gorkhaan's Homepage
- A hozzászóláshoz be kell jelentkezni