[megoldva] root a RAID1 -en

Linux-haladó

Adva van két 500 GByte -os SATA HDD. Erre kellene Debiant pakolnom, és RAID1 -et akarok. Viszont hova tegyem a rednszert és a swap -et?
Ha ezt is RAID1 -be rakom akkor elég lassűlessz a dolog különösen a swap, ami mivel 4 GByte RAM van legalább 8 GByte -os kellne hogy legyen (ököl szabály).
Van valami 5let, tapasztalat vagy tanács?

  • 3118 megtekintés

( pinyo_villany | 2008. 05. 13., k – 17:49 )

boot -> (sda1 sdb1) - md0 - raid1
swap -> (sda2 sdb2) - nyers
root -> (sda3 sdb3) - md1 - raid1
var
tmp
usr
home
szerk.: fix

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

A swap-nak van egy prio kapcsoloja, amit fstab-ba is meg tudsz adni (man swapon). Lehet ugy csinalni a raidet, hogy a swap kulon van (nem raidelt) es mindket winyora kulon tud swapolni. Elonye, hogy gyors, hatranya, ha behany az egyik winyod akkor garantalt, hogy bizonyos alkalmazasok adatot vesztenek.
Ja, a lesz 1 "sz" ;)
--
TH

( wildy | 2008. 05. 13., k – 17:48 )

Ha nem akarsz szethullo gepet latni mert elrepult alola a swap, akkor RAID1-re vele. 8GB felejtos, csinalj max 1-2GB-ot. Talan a 2.4-ig volt ervenyes a fizikai memoria * 2, azota kicsit jobb a VM. A root fs szintugy RAID1-re valo.

+1

SAP azért tud 4GB-nél többet igényelni //gép 5 (8G mellett 20G swap) 


zgrep Swap log.gz | awk usedcolumn | sort -nr | head
[0]
3094308
3018808
3013144
3008888
2996716
[1]
3351768
3315340
3308112
3281660
3256996
[2]
73508
73304
72852
71700
71660
[3]
369500
369220
369072
369060
369044
[4]
1436760
1436548
1434952
1434912
1434832
[5]
4434600
4393224
4386464
4369404
4348544
[6]
3466544
3441924
3397992
3306436
3280872
[7]
169632
169632
169632
169632
169628
[8]
176340
174932
174580
173752
173320

( maszili | 2008. 05. 13., k – 18:06 )

Ha a swap teruletet uzemszeruen (allandoan nagy teruleteket) hasznalja a szerver akkor az mar regen rossz... ezert en nem aggodnek azon, hogy lassu lehet. Egyebkent meg nem lesz lassu raid1-en.

Ha nem szeretned elrontani a rendelkezesre allast akkor _mindent_ raid1-re erdemes rakni. Ebben az esetben ne felejtsd el a rendszerbetolto (grub) helyes konfiguralasa utan mindket diszkre telepiteni a rendszerbetoltot. Mert ha csak az egyken van es pont az szall el akkor nem tudod elinditani a rendszert a masikrol ha nincs azon is a rendszerbetolto.

--
maszili

Grub megfelelo beallitasa...

/boot/grub/menu.lst 

title   Debian GNU/Linux, kernel 2.6.24-1-amd64 (SDA)
root    (hd0,0)
kernel  /vmlinuz root=/dev/sda1 ro
initrd  /initrd.img

title   Debian GNU/Linux, kernel 2.6.24-1-amd64 (SDB)
root    (hd1,0)
kernel  /vmlinuz root=/dev/sdb1 ro
initrd  /initrd.img

Mindket diszkrol tudjon rendszert betolteni, ha valamelyik kiesne.

Majd mindket lemezre telepiteni is kell...

grub-install /dev/sda
grub-install /dev/sdb

--
maszili

Javits ki ha tevedek de szerintem nem sok ertelme van az lvm-nek...
Mert mi tortenik ha meg szeretne novelni egy fajlrendszer meretet?
Novelni kell a particiot (lvm) ... de ezt csak valaminek a karara lehet. Vagyis valamit meg csokkenteni kell.
Ha mezei ext3 fajlrendszert hasznal akkor ez eselytelen. Kovetkezeskepp folosleges az lvm-el tokolni mert ugy is az lesz a vege hogy ujbol letre kell hozni egy (tobb) fajlrendszert.
Ha tudja, hogy mit fog csinalni a szerver akkor tud elore tervezni es nem fordulhat elo hogy rovid idon belul kifut a szabad helybol.

--
maszili

De igenis erdemes. LVM-vel feldobod a base rendszert egy raid-os akarmire, aztan 3 evet raersz azon filozofalni, hogy mit kell es mit nem kell novelni.

Novelni lehet online, es semminek sem megy a karara, mert pl. egy 160GB-os lemezen install utan (es miutan ugy kb-re belotted mit akarsz vele csinalni) maradsz meg vagy 100GB hellyel.

Úgy látom, még nem használtál LVM-et :-)

Valami kárára lehet növelni: a valami a jelenleg kiosztatlan terület. Felesleges mindent kiosztani az elején.

Mezei ext3 fájlrendszert lehet növelni is, csökkenteni is. Nem kell újra létrehozni semmit.

Nekem van egy gép, van rajta fileserver meg levelezés.

Én úgy gondoltam, majd a home jó sok kell, meg minden. Aztán az üzem közben kiderült, hogy nem. A /var/mail kötet a legnagyobb, egyszer a /usr-t is növelni kellett, mert kiderült, hogy kell valami új program, ami baromi nagy volt, a /home-ot azóta jól lecsökkentettem. Egyedül a /export - fájlszerverrel kiajánlott közös területe volt kb. az elképzelések szerint. (De azon is kellett növelni, mert persze nem adtam neki rögtön mindent).

G

A grub szerintem vitathato. En is nagy grub-hivo addig amig nem akart feltelepulni egy hw raid-ra. Aztan kiderult, hogy sw raid-on is egyszerubb a lilo-t hasznalni. Nem kell sz*rakodni, hogy egyik lemez masik lemez, most bootol e vagy nem, stb, stb.

Lilo egyszeruen megy (egy + sorral a lilo.conf-ban).

Én csak a saját tudatlanságomban hiszek! Nem ismerem a grub -ot és eddig mindíg, amikor nem sikerült valamit lilo -val megoldanom, kiderült, hogy én vagyok buta, és igazából még a lilo -t sem ismerem eléggé :)
Más nem fér a fejembe. Ha megáll az egyik disk a tömbben, a root partíciól akkor mi is fog történni? Mit akarna bootolni a lilo (vagy a grub)? Továbbra ius az md0 -át, onnan is előszőr (gondolom) a kernel imaget és valamikor az initrd.img, persze mindezt úgy, hogy lehet pont az a disk tartalmazza az mbr -ben a lilo -t amelyik tönkrement! -vagyis nincs mit bootolni? De mi van ha a másik disken ott van a jó mbr?
Nekem ez nagyon zavaros :(
Amikor a BIOS elindítja a bootlhatónak itélt disket, fogalma sincs hogy az valami tömbben van. Teszem azt hogy az md0 a /dev/sda1 és a /dev/sdb1 ből áll össze, azonban a BIOS azt kapja elő ami a listájában előrébb van - /dev/sda1. Ott viszont sérült a cucc - összeomlik! Ha ilyen van akkor fizikailag ki kell szedni a /dev/sda1 -et és reménykedni, hogy a /dev/sdb1 működőképes? Szerintem, a raid csak akkor tud hasznos lenni ha a rendszer egyébként fut. Ha a raid hibádzik, akkor nyerőbb egy rescue rendszer, amivel újra húzhatod a raidet.
Azért is vetettem fel az egészet, mert a raid nem oldja meg a rendszer partíciók sebezhetőségének problémáját. A RAID az adatok biztonságát tudja hatékonyan támogatni. Ha nem lennének a /var és a /tmp könyvtárak egyszerűen egy CD -ről lehetne tölteni a rendszert, hiszen szinte változatlan. Ez lenne az igazi megoldás, egy kis rendszer, bele a RAM -ba, és csak a változó dolgok valahol a lemezen.

* Én egy indián vagyok. Minden indián hazudik.

Ha az első diszken nincs bootmgr, bootol a másikról. A bootmgr meg szépen felfogja, hogy féllábú a raid, és bebootol a féltükörről. Vagy nem...? A CD-ről induló readonly rendszer plusz némi ramdiszkre a konfig, plusz a változó cuccok vinyóra -- nos, ez létező megoldás, plédául a Devil linux így dolgozik...

SW raid-ot elsősorban nem arra találták ki, hogy teljesen fail-safe legyen. Erre jó a hw kontroller, ami el tudja dönteni, hogy melyik lemez megbízható s melyik nem. SW raid arra jó, hogy ne kelljen 5 órán keresztül vakarni a backup-ot, és addig a cégnek elvérezni. Amúgy általában nem bootoláskor (ami szervernél ugyebár nem normális üzem) szokott meghalni a lemez, s menet közben egyszerűen kipotyog a raid-ból, ha gond van. Ha tényleg gond van a lemezzel hot-swappelsz egy újat, és resync. Ha pedig nem hot-swap akkor leállás, csere, újraindítás. Nem kell egyik lépésnél sem a rescue-lemez, mert maga a rendszer felbootol és normálisan működik.

Akkor a legegyszerűbb, ha meghal teljesen a lemez. A lilo-nak raid-os konfigurációban semmi köze az sda es sdb-hez. Egyszerűen az md0-t kezeli root-ként, installálódni is oda installálódik (mbr-be, itt nyilván megjelenik az, hogy sda sdb), ezt kell neki még egy paraméterrel elmagyarázni. Ha kiveszed egyik diszket, ugyancsak md0-t lát (de mbr nyilván a másik lemezről van).

Kicsit zavaros voltam, tudom. Éppen a tequila-ról dokumentálódtam...

( tovis v | 2008. 05. 13., k – 18:28 )

Jó, meghajlok az érvek előtt - én sem láttam még, hogy valamim kihasználta volna a swap -ot, amit én reszketeg aggastyán képpen 2xRAM méretűre rakosgatok.
Nekem akkor valami ilyen lessz a kiosztás:
sda1 sdb1 md0 - root, ck. 5 GByte (X nem lessz)
sda2 sdb2 md1 - swap, ck. 5 GByte
sda3 sdb3 md2 - /home ck. 350 GByte
sda4 sdb4 md3 - /vlmi ck. 100 GByte SQL adatbázisok

Másik probléma lehet, hogy külön topicba kellene tenni?
Van egy harmadik SATA 500 GByte HDD - ő lenne a backup, hideg tartalékban. hotswap -ként akarom használni, ezért bedugtam a gépbe egy sil3114 -es zsugát. Úgy tűnik mükszik vele.

... megjegyzés
... volt egy rossz köröm, amikor a rendszert egy IDE HDD -re tettem, de
... azzal időnként összeakadt - 3 -ból egyszer tuti -
... hda: dma_time_expiry: dma status == 0x61
... ezért kell mindent a SATA -ra bízni akkor nincs összeakadás

Viszont ggond van a device kiosztásokkal, valahogy rá kellene venni a rendszert hogy újabb SATA/USB/SCSI eszközöket csak a /dev/sde -től kezdve osszon. Csinált már valaki ilyet?
Az udev doksikban lehet a persistent listákat módosítani és valami egyedi nevet osztani, de nem tudom hogy fog ez összejönni a softver RAID -el.

* Én egy indián vagyok. Minden indián hazudik.

Nem-nem.
A particio UUID != Raid UUID. Mig a part. uuid-ot a fstabban hasznalod, es a blkid vagy a vol_id van a segitsegedre a kideriteseben, addig a RAID UUID a tukor ket oldalat azonositja, es mindentol fuggetlen egyedi. Pont ezert nem megadhato, mert igy automatice el van kerulve a user error veszelye (veletlen eltalal egy masik, letezo uuid-et).

Ha a tombbe kell winyo, akkor a mdadm-mal lehet a tombhoz eszkozt adni.

Minek ekkora root particio?

Tedd a /usr-t külön, és read-only-ba, tedd a /boot-ot külön, és read-only-ba
/var legyen külön, ha valami log teliteszi, ne vigyen el minden helyet. Esetleg /var/log külön, /var/mail külön

Nekem egy tipikus root partíció pár száz mega szokott lenni. Főleg a /lib miatt. Legyen benne kb. két kernelnyi modulnak szabad hely, és kész.

Érdekes megoldás, de nekem kicsit zavarosnak tűnik :(
Tehát:
1 partició 300 MB / read-only
2 partíció 8 GB swap 2xRAM
3 partíció x GB /usr read-only
4 partíció y GB /var rw
5 partíció z GB /home rw
6 partíció w GB /mnt/data rw SQL adatbázis terület

Ez szép de ijesztő :x
A /var és a /usr tartalmaz számos nagyon fontos adatot. A Debian esetében, itt van az apt cache, ha ez elvész helyreállítani nem igazán lehet. Ha nem teszed valahova el, az SQL szerverek is a /var -ba pakolják az adatokat, nem beszélve a var/lib és egyebekről. Lehet hogy egy virtuális és valós felhasználóktól hemzsegő - több ezer - felhasználónál ez a bonyolultság hasznos de nekem mindösszesen úgy két tucat felhasználót kell ellátnom, jól körülhatárolt szolgáltatásokkal, mondjuk a levelezés a /home -okban Maildirben lessz és effélék.
Az a 8 GB root pontosan elég lessz (inkább sok), ha ebből a /usr vagy a /var oldalon valami "kitör" az más gondra utal.

* Én egy indián vagyok. Minden indián hazudik.

/boot menet közben nincs felcsatolva
Ez miert jo?

/usr meg ro,nosuid,nodev,
A root-on kivul mas nem irhatja ezert nem latom ertelmet... ha root jogot szerez valaki akkor meg ujracsatolja.

De mi van a /var/tmp-vel? Az mindenki szamara irhato! Azt miert nem kell kulon particiora rakni NODEV,NOSUID,NOEXEC?

--
maszili

Ha arra gondolsz, hogy a /boot /usr küülön, a /var/tmp miért nem... A partíciókat első körben a csatolási paraméterek kölönbsége miatt szedném szét, és csak másodsorban a helyigény, illetve annak dinamikus változásai alapján. A /var/tmp -t ott, ahol sokat használják a userek, jelentős a foglaltság változása, ott lehet, hogy külön szedném, egy logszerveren meg a gyűjtögetett naplók mennének külön partícióra, egy webproxy esetén meg természetes, hogy a cache-terület kapna külön stripe-olt területet, akár úgy, hogy noauto, majd az initscript megnézi, hogy az adott partíció normálisan lett-e lecsatolva, és ha nem, akkor fsck helyett mkfs, majd mount.

Meg mindig nem ertem, hogy miert szukseges a /usr-t kulon particiora rakni.

Egy kesz rendszer eseten nem no a merete szamottevoen mert uj programok nem nagyon lesznek telepitve, hiszen a rendszer egy elozetes terv alapjan keszre van konfiguralva. Tehat a meretevel jol lehet kalkulalni. Biztonsagi szempontbol meg nem ertem, ha egyebkent is csak a root tudja irni akkor en feleslegesnek erzem a read-only fajlrendszert.

Ellenben a /var/tmp konyvtarat barki irhatja (akar csak a /tmp-t) ami biztonsagi szempontbol kockazatot jelent. Ilyen esetben indokolt az olyan fajlrendszer amin korlatozasok vannak.

--
maszili

Nem szükséges, hanem szokásos, illetve ott a nodev mindenképp játszik, a nosuidnak meg jó esélye van. "A root tudja írni csak, akkor minek a ro mount"... Mert a root is lehet fakezű, vagy csak álmos, figyelmetlen -- nem jó dolog a rendszer valamely vitális komponensét véetlenül felülvágni vagy törölni egy mellényúlással. A ro mount tehát az üzemeltetési hibából adódó kockázat csökkentésére is alkalmas, de egy feltételezett fs-jogosultság megkerülését lehetővé tévő sérülékenység kihasználását is minimum megnehezíti.

Nem szükséges, hanem szokásos,
Hát ez fából vaskarika :)

illetve ott a nodev mindenképp játszik, a nosuidnak meg jó esélye van.
Nade ha a root-on kívül senki másnak nincs írási joga az adott könyvtárra akkor mi értelme?
Ha egyébként sem tud senki (a root-ot kiveve) oda írni akkor eszközleíró fájlokat sem fog tudni létrehozni... következésképp mire fel a NODEV?... vagy hasonlóan a NOSUID?

A /tmp és /var/tmp esetén a korlátozások értelem szerüen megakadályozzák, hogy bárki ott futtassa a futtani kívánt kártékony programját.

A ro mount tehát az üzemeltetési hibából adódó kockázat csökkentésére is alkalmas, de egy feltételezett fs-jogosultság megkerülését lehetővé tévő sérülékenység kihasználását is minimum megnehezíti.

De akkor lehetne az összes további partíciót read-only felcsatolni. Miért pont a /usr ?

Tényleg nem kötekedésből kérdezem... csak már több fórumon is olvastam, hogy a /boot /usr külön partícióra menjen. Ha a /boot más fájlrendszer esetén vagy egyéb rendszerindítási gondok miatt kerül külön partícióra azt megértem. De ez is egyedi eset és nem gyakran előforduló helyzet lehet.

Tehát ezért kérdezem, hogy miért szokás pont a /boot és /usr könyvtárakat külön partícióra rakni.

--
maszili

A /boot-ot altalaba azert teszik kulon, mert a kernel igy vedve van egyfelol a rm -rf /* ellen (a kernelnek ugyanis normalis rendszeren nem kell leteznie, kovetkezeskepp a /boot-nak nem kell mountolva se lennie), masfelol pedig az esetleges fertozodes ellen is kap neminemu vedelmet.

A /usr-rel kapcsolatban: alapvetoen egyebkent en se szokom kulon tenni, de altalaba foleg azert, mert egy szerveren nem feltetlen csak 1 ember tudja a root jelszot, hanem tobb is. Oke, hogy te nem torolgetsz veletlen semmit, de vajon megbizol a masik rendszergazdaban is ennyire? Okos ember nem teszi, hiszen alapveto a bizalmatlansag ilyen teren. Tenyleg nem jo moka egy atbulizott ceges szilveszter utan szervert ujratelepiteni.
Ezenfelul szinten exploitolodas elleni vedelem is, hiszen igy az esetleg root-tal futo szerver sem kepes a sajat binarisat felulirni, hiszen ro van mountolva a part.

Oke, hogy te nem torolgetsz veletlen semmit, de vajon megbizol a masik rendszergazdaban is ennyire?

De miert pont a /user ??? :) A /bin /sbin /lib stb... nem fontos?

Tenyleg nem jo moka egy atbulizott ceges szilveszter utan szervert ujratelepiteni.
Jaj ne mar... ez olyan eroltetett indok.

Ezenfelul szinten exploitolodas elleni vedelem is, hiszen igy az esetleg root-tal futo szerver sem kepes a sajat binarisat felulirni, hiszen ro van mountolva a part.

Csak ismetelni tudom a kerdest...
De miert pont a /user ??? :) A /bin /sbin /lib stb... nem fontos?

--
maszili

A / _is_ ro, viszont a /usr az nosuid _is_.

Ha jol latom akkor pl. ilyen programok vannak SETUID bittel a /usr alatt:

maszili:~# find /usr/ -perm -4000
/usr/sbin/pppd
/usr/bin/fileshareset
/usr/bin/lprm
/usr/bin/pmount
/usr/bin/sudo
/usr/bin/procmail
/usr/bin/lpq
/usr/bin/gpasswd
/usr/bin/start_kdeinit
/usr/bin/mtr
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/kgrantpty
/usr/bin/pumount
/usr/bin/X
/usr/bin/kpac_dhcp_helper
/usr/bin/lpr
/usr/bin/sudoedit
/usr/bin/at
/usr/bin/newgrp
/usr/bin/kppp
/usr/bin/passwd
/usr/lib/apache2/suexec
/usr/lib/pt_chown
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign

Tehat ha a /usr NOSUID opcioval van felcsatolva akkor ezek nem biztos hogy jol fognak mukodni.
Ezek utan meg mindig nem latom ertelmet kulon particiora rakni a /usr konyvtarat... foleg azert, hogy NOSUID opcioval legyen.

Az szamomra szakmailag nem elfogadhato indok, hogy a másnaposan részeg, 3 napja kialvatlan, belőtt rendszergazda letörölheti :)

--
maszili

( KLajos | 2008. 05. 13., k – 21:38 )

Mi a véleményetek a partícionálható raidről?
Nekem bevált, és könnyebben rekonstruálható, ha hibázik az egyik disk.

Én így csináltam a raid1-et, szintén sata diskekkel:
/dev/sda, /dev/sdb -> /dev/md_d0 (raid1)
és utánna az md_d0 -t partícionáltam:
/dev/md_d0p1 -> boot
/dev/md_d0p2 -> root
/dev/md_d0p2 -> swap
stb.

( talisker | 2008. 05. 14., sze – 09:41 )

Bár már sokan sok okosat mondottak,
véleményem szerint 4GB feletti méretű swap-nak nincsen sok értelme. Igaz ezt RedHat-es források mondják.
Szerintük RAM*2 swap kell, amíg az nem nagyobb 4GB-nál. (Ergo 3GB RAM-hoz is max 4GB swap-et ajánlanak.

A swap-et is nyugodtan lehet rad-elni. Nem fog teljesítményveszteséget okozni. Ha meg mégis ezt tapasztalod, akkor ne raid1-et, hanem 5-t használj. Az valamivel gyorsabb.
Bár nekem a raid1 teljesen jól műxik teljesítmény tekintetben is.

Viszont raid esetében minden olyan eszközre fel kell rakni a GRUB-ot, amelyiken a /boot lesz.
Ha ez neked külön partíció, akkor azt, ha nem akkor a / (root)-ot.
Pontosítva: minden olyan eszköz MBR-jében lenni kell grub infónak, amely raid tömb részét képezi a fentebbi viszonylatban.
Ezt épp pár hete szívtam meg. Elment az egyik diszk, pont, amelyiken a rendes grub boot cucc volt.
A másiknak meg nem volt az MBR-jében semmi. Kézi hekkeléssel végülis fel lehetett izgatni.
Kellett egy grub installt csinálni.

Az szerintem ízlés kérdése, hogy egy diszket egyből raid-elsz, vagy partíciónként párban mondod, hogy melyik 2 legyen egy raid pár. Nálam két diszk van 3-3 partícióval, páronként raid1-elve.

Nekem ext3-mal tökéletesen megy az LVM. Azokra helyekre, amelyek nem pontosan belőhetőek, hogy mekkorára híznak majd, kiváló megoldás az LVM. Később lehet tologatni ide-oda a méretet és az ext3-t is utána lehet kötni röptében.

Mindenjókat.

---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Swap és a RAID... Hnam csak lehet, hanem erősen javasolt, hiszen a fs ugyan túlél egy diszkhalált, de a rendszered tutira nem, hiszen egy korrupt terület belapozása igen kellemetlenül érinti az adott alkalmazást -- szerencsétlen esetben a fs is összegubancolódhat swaphiba miatt.

Nem akartam ilyen direkt lenni, még valami űberkúúl kernel hacker elküld melegebb éghajlatra.

Természetesen erősen javasolt a swap raid-elése. RHEL tanfolyáson okosok is ezt javasolták. :))

szóval +1
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Olvasod, vagy írod? Olvasás esetén a tükör két feléről lehet round-robin olvasni (gyors), írni viszont kétszer kell kétszer kell (lassú). Persze az is kérdés, mikor mondja a RAID-réteg (szoftver/adapter), hogy készen van az írás, elég-e egyszer áttolni a kiírt adatokat a buszon (adapter elintézi a több diszkre írást, illetve (RAID5) a szükséges olvasásokat), vagy szoftosan csinálod, és a kiírásra kerülő adat kétszeresen terheli kétszeresen terheli a buszt...

Azt kell kitalálni, hogy mi lesz a jellemző terhelés, milyen burst-jellegű folyamatok fognak lejátszódni a rendszerben, mire kell kihelyezni a tárolórendszert -- nem egyszerű a feladat, bár home PC-s reszelés szinten úgy nagyjából tök mindegy (négy diszkig pláne).

olvasasra raid1, raid5 is 2 lemezt hasznal (ha feltetelezzuk, hogy raid1 alatt 2 vinyo, raid5 alatt 3 van) szerintem.
irasra meg hw raid eseten egyforma gyors (hisz a kari szamolja a paritast), szoftveresen lassabb lehet, pont emiatt.

ha raid5be tobb vinyot raksz, akkor tenyleg gyorsabb, mint egy mezei raid1 (de abbol meg csinalhatsz raid10-et), de ott meg minnel tobb lemezt raksz bele, annal nagyobb lesz az adatvesztes kockazata (3bol2 vinyo kissebb esellyel pusztul el egyszerre, vagy a rebuild alatt, mint 20bol 2)
szoval ha sok lemez van akkor vagy valami tobbszintu raid1/0 vagy raid6.

Tyrael

( arpi_esp v | 2008. 05. 14., sze – 14:57 )

ez a swap=2*ram kb 10 eve volt igaz, amikor meg jocskan 100 mega alatti memoriak voltak.

en mar 256mb ram melle se rakok swappet, de 1g-tol folfele mar tenyleg semmi ertelme. plane a mai memoria arak mellett, ha ennyire memoriaigenyes alkalmazast futtatsz, inkabb vegyel tobb ramot.

A'rpi

Van értelme a swap-nak. Mikor elkezd vadul swap-olni küldhet egy snmp trap-et, hogy valami nem okés. Van idő ránézni és nem szakad meg a szolgáltatás. Minél nagyobb a swap, annál több idő van. Volt egyszer egy ilyen esetem, s mikor betelt a (kicsi) swap, elment az egész rendszer. Amíg volt üres swap-terület még mozgott rendesen.

Normális üzemben nyilván nincs sok értelme, csak arra jó, hogy swap-olással felszabadíthat ideiglenesen egy éhes alkalmazásnak memóriaterületet.

( tovis v | 2008. 05. 15., cs – 17:16 )

Kezdek becsavarodni. Az egész telepítés Debian Etch.
Felcsináltam egy kis rendszert a /dev/sda1 (swap /dev/sda5 - logikai).
Az mdadm -hoz tartozó rootraiddoc.97.html alapján, lépésről-lépésre haladva létrehoztam a raid1 -et a /dev/sdb -n (a /dev/sda particióit használva - mindkettő azonos hdd) létrehoztam egy féllábú raid1 -et, felmásoltam a rendszert, bebootoltam a boot=/dev/sda és root=/dev/md0 -ba, majd beépítettem a /dev/sda1 -et a riad1 -be és beállítanám a lilo -t hogy bootolhassak a /dev/md0 -ról. Első nekifutásra beállítottam a lilo -t "raid-extra-boot=mbr-only" -ra - a teszt nem mondott semmi különöset, viszont bootolni sem tidtam L99 ...
No még egyszer ...
Most már elkezdtem játszanio a "raid-extra-boot" paraméterrel, átolvastam a README.raid1 című dokumentációt a lilo -hoz, átnéztem az internetet (kicsit), még itt ahup -on ius találtam valamit - de ott az upgrade után t9rtént valami.
1. ha raid-extra-boot="/dev/sda,/dev/sdb" - lilo -t -v
... leáll fatal -lal nem tud írni a raid1 -be!?
2. ha teljesen kjiveszem ezt az "raid-extra-boot" micsodát, ahogy a lilo doksi javasolja azonos diskek esetén - lilo -t -v
... The map file has *NOT* been updated.
... The boot record of /dev/md0 has *NOT* been updated.

így eleresztettem a lilo -t, erre a következőt írta:
The boot record of /dev/md0 has been updated.

Na most akkor mi van? - bug. dd -vel kikaptam az MBR -t, az különbözik (a /dev/sdb csak valami kis szemetet tartalmaz).
Ez így ha lefittyed a /dev/sda nem tud bootolni, akkor most mit lehet mit is update -elt?
És végül, a lényeg hogy tudom a helyes MBR -t beállítani?

* Én egy indián vagyok. Minden indián hazudik.

Ezt igy fejbol regi emlekek alapjan irom csak, de elegge logikus volt, mikor egyszer csinaltam anno. A particionalos resznel megcsinalod az egyforma meretu particiokat a ket disken, es meg lehet adni hogy azt milyen mdX -nek rakja ossze, es az mdX-et adod meg a mountolasi pontnal..., mindez a konzolos telepitoben volt, a kezi paticionalasnal. szerintem

( gthomas | 2008. 05. 15., cs – 18:29 )

Háát, nekem a statisztikai számításokhoz (R) most gondolkodok a 64 bitre váltáson (32 biten 3Gb a max. kiadott memória egy processznek, és kevés), úgyhogy kijelenthetem: kell a swap 2Gb memória mellé is :)

( tovis v | 2008. 05. 15., cs – 18:40 )

Müködik! :D
Most már csak arra kellene rájönnöm hol rontottam el! -[
Adott esetben a dolognak nincs jelentősége (megoldva, kipipálva) azonban ha egy már működő rendszert kell raid -be tenni azért nem hátrány a kézi módszert kitanulni.
No és hát igen, most jön a tzesztelés - hotplug mentést szeretnék ugyancsak SATA -ra. Egy már működő verzióban kiderült hogy az addigi konfigurációval a hotplug sata összeakad a /dev/hda -val:
dma_timer_expiry és kampó, no de most? - majd jelentkezem.
Addig is ha tudtok valami kicsit komolyabb benchmarkot mint a hdparm (az csak olvasgat) akkor kérlek szóljatok.

* Én egy indián vagyok. Minden indián hazudik.

( tovis v | 2008. 05. 16., p – 18:54 )

Végül úgy tűnik összeáll!
Az első próbálkozásokra működik a SATA hotplug is :D
Úgy próbálgatom a dolgot, hogy közben írok a ck. 340 GB -os /home partícióba (raid1, lvm2), a következő képpen:
dd if=/dev/urandom of=stuffed.with.urandom bs=1024 count=1048576

ez létrehoz egy 1 GB -os fájlt, ck. 3 MB/sec mond rá a dd. De ez valszeg sebességre nem az igazi :( nem tudom mi ez az idő.
Közben pedig ki/be kapcsolgatom a hotplug SATA drive -t, irogatok rá, fsck -t futtatok rajta - egyenlőre tűri :)
Jó lenne valami korrektebb írási sebsség teszt. Tudtok valami egyszerűt?

* Én egy indián vagyok. Minden indián hazudik.

Hoppá! - a /dev/zero tényleg jóval gyorsabb. Nem gondoltam, hogy a random szám generálás ekkora feladat neki.
Kipróbáltam az otthoni "szerveremen" (2xP3 500 MHz egy nagyon antik GigaByte alaplapon Ga-6bxds) az is "megtáltosodott" a randommal vlmi 750KB/sec a zeroval 16MB/sec, ez is raid1 és lvm - ez azért szép ettől az ócskvastól - no meg a pingvintől!
De jellemző rám, hibázik a hotplug (fsck) és miníg eggyel feljebb épül be(sdc,sdd,sde) - aztán leesett, elfelejtettem umount -olni :)
A rendszer azonban szépen tűri :)

* Én egy indián vagyok. Minden indián hazudik.

Bocs, ezt nem figyeltem, de amikor "kilépett" a parancsból vissza a shell -be akkor írta ki ezeket az értékeket - annyira nem vagyok megszálott, hogy stopperrel méricskéljek :)

Az eredeti probléma megoldódott/eldőlt így a következő struktóra alakult ki:
md0 - root - sda1,sdb1 - 8G (figyelni kell ki, mit és hova pakol)
md1 - swap - sda5,sdb5 - 8G (biztos ami biztos)
md2 - lv0/darea - SQL - sda6,sdb6 - 100G
md3 - lv1/harea - /home - sda7,sdb7 - 340G
így be is telt az "500" GB, ha kell még valami ott az lvm :)

* Én egy indián vagyok. Minden indián hazudik.

1. Mi az az RTM?
2. Menetközben, hosszútávon átlagos terheltségek mellet nyugodtan számolhatsz ezzel az idővel. Akkor lehet ezzel a "méréssel" gond, ha mondjuk DVR -t csináész - csak hogy én is mondjak egy szép rövidítést. Számos, PC alapú DVR -el találkoztam, amelyek 24 órában rögzítik a akár 16 kamera képét egyszerre, tömörített formátumokban. Itt valószínűleg eljutsz oda, hogy az asynchron syncronná válik.

* Én egy indián vagyok. Minden indián hazudik.

1. RTFM finomabb formája.
2. Felejtsd el ezt az időt. Szekvenciális íráskor sem tudja huzamosabb ideig ezt az adatátvitelt tartani. Random esetén meg 20-30Mb/sec nek is lehet occsó SATÁn örülni.

PC alapú DVR inkább szekvenciális IO-t generál. Sok köze nincs a példádnak a szinkron-aszinkron kérdéshez.

Szép, szép ...
Azonban próbáltam ezt vagy 20x egymás után újabb és újabb fájlba és nem érzékeltem különbséget 8-9 sec, és a végén egy sync, ami (megérzésre) ugyanaddig tartott. Egyébként ez valószínűleg nem lessz annyira kritikus. De ha tudtok valami jobb tesztet - ide vele, még lehet.

* Én egy indián vagyok. Minden indián hazudik.

rtm = read the man(ual)

arra próbált célozni, hogy az FS-ek cachelnek, ha async módban vannak.
ha a parancs végén tolsz egy syncet, akkor kitolja hdd-re is

pl.: dd if=/dev/zero of=/file ... && sync
vagy
time ( dd if=/dev/zero of=/file ... && sync )

debian gnu/linux @ linux-2.6.22.24-op1 | patch
info

Fiuk, pontosan tisztában vagyok az asynchron dolgokkal OS szinten. De azzal nehezen tudok mit kezdeni hogy ez hogyan tükröződik egy működő rendszeren. Többre becsülöm a tapasztalati adatokat, mint az elméletet. Egyébként is az elmélet arra való hogy megmagyarázd a gyakorlatot :)

* Én egy indián vagyok. Minden indián hazudik.

A működő rendszeren ez úgy tükröződik, hogy a programok által fs-re küldött adat valójában a file rendszer bufferében tárolódik.
Ez azt jelenti, hogy a cache méretétől függően látszólag igen sok adatot képes baromi gyorsan írni a rendszer.
A lassulás ott következik be, amikor a FS cache -ből fizikailag is a diszkre kerülnek az adatok.
Ráadásul a diszkek is tudnak hasonló dolgokat produkálni.
A hirtelen nagy mennyiségű adatot egy ideig jól "elnyelik" (burst rate), viszont hossú ideig tartó írás esetén ez a teljesítmény jóval kevesebb. (sustained rate)

További fontos dolog, hogy az IO elég ritkán mutat szekvenciális mintát.

Tipikus random io: OLTP adatbázisok, file szerverek sok kicsi fájlal.

Random IO esetén pedig megjelenik mint probléma a disk seek-time. Vagyis a teljesítmény erősen csökken, mert megnő a diszk pozicionálásához szükséges idő. Írás esetén a diszkek vezérlőjébe épített cache képes ezt kompenzálni, viszont a buffer telítődése után az IO teljesítmény romlik.

Ha diszk IO tesztet akarsz fájlokkal végezni, akkor mindenképp a memória méreténél nagyobb mennyiségű adat írására van szükség.