[megoldva] raid1 --create lassú - emlékeztető

Fórumok

Adott két épp a csomagból kibontott 500G diszk, amit egy kis szerverkébe készítek. Megkíséreltem a Debian telepítővel particionálni, de az eredménnyel nem voltam elégedett, űjra neki szaladtam RIP segítségével és azt tapasztaltam, hogy a zsír új diszkeket az md hosszan és kitartóan elkezdte szinkronizálni - több mint egy óra után, nem bírtam cérnával és írtam egy "flame" típusú blog bejegyzést. Mire kaptam egy nagyon építő (legalábbis én mindenképp profitáltam belőle) választ, hogy a kreáláskor, ilyen esetben (új, üres diszk) érdemes bevetni az "--assume-clean" kapcsolót. Így elkerülhető a hosszú szinkronizáció.
Mivel ennek az opciónak a használatával eddig nem találkoztam, számomra meglepő volt, nagyon örültem neki, de ezzel a válasszal megsértettem a blog bejegyzésekre vonatkozó irányelveket, így a bejegyzést törölték.
Úgy döntöttem akkor egy ilyen kis bejegyzéssel korrigálom a dolgot, hogy a megoldás ne vesszen el az éterbe, és mások már ne szakadjanak bele.

Az irányelvek megsértéséért elnézést kérek!

Hozzászólások

Ez most off lesz, de ezzel kapcsolatban merült fel bennem: pontosan mi is történik egy ilyen szinkronizáció esetén? Ha eltérő adatokat talál a két winyón, márpedig miért ne találna ha mondjuk randommal van tele, akkor mégis melyiket másolja rá a másikra? Mivel az MD nem látja a fájlrendszert, így elvileg azt sem tudhatja, hogy tulképp dontcare adatokról van szó. Ez valahogy mindig homályos volt nekem.

Tudtommal, (de az okosabbak kijavítanak majd) a raid nem azt "tudja", hogy melyik szektor up-to-date, hanem a szuperblokk-ban az van eltárolva, hogy melyik diszk volt utoljára (sikeresen) írva. Így ha eltérés van, akkor resync lesz belőle. Azaz (valószínű) nincs vizsgálat szektor szinten, hanem csak másolás.
--
Debian Linux rulez... :D

Na ez jó kérdés! :D

Pár lehetőség lehet.

Ha megegyezik a két diszk akkor ugye nincs szinkronizálás. (Ez induló RAID esetén kiesik :D)
Ha valamelyikről el tudja dönteni, hogy "frissebb", akkor azt a másikra. Ez alatt az is érthető, hogy ha a másik szuperblokjában csak 0-ák vannak.
Ha mindkettő érvénytelen, akkor szerintem "PENDING" lesz... És ha fájlrendszert hozol létre, azaz írsz rá, akkor kezdi el összerakni. Itt meg gondolom vagy véletlenszerűen választja az egyiket, vagy valamilyen programozott szabály szerint (pl. a 0-ás azonosítóval rendelkezőről) másolja át az adatokat.
--
Debian Linux rulez... :D

ÚJ raid1 létrehozásakor mindegy melyiket melyikhez szinkronizál.

Diszkhiba esetén a kiesett diszket "rossz"-nak jelöli meg.
Nyilván a belerakott csere diszk esetén egyértelmű, hogy melyik diszket melyikhez szinkronizálod.

Ha elmegy a betáp akkor probléma van.
A RAID-et nem a tápkiesés ellen, hanem a diszkhiba ellen találták ki. Betáp kiesés után alap esetben nem lehet eldönteni melyik diszk legyen a resync forrása. (hacsak nincs dirty region logging -lásd lejjebb)
Még ha pl. raid1 esetén a két diszken tök ugyanaz van, akkor is simán lehet elveszett IO, és így mindenféle adathiba.
Táp elszállás esetén érdemes a széthullott raid1 diszkjein külön-külön fsck-t futtatni, és amelyik nem jelez hibát, abból újraépíteni a raid-et.

Létezik egy write intent bitmap (vagy dirty region bitmap - ki hogy hívja.)
Elvileg ez alapból nincs bekapcsolva, (mert kicsit lassítja a raid tömb írását) viszont egyrészt arra jó, hogy megmondja melyik diszken van a jó adat, másrészt a resync-et is felgyorsítja, mert nem fog mindent újraszinkronizálni , csak azt ami nem konzisztens.

https://raid.wiki.kernel.org/index.php/Write-intent_bitmap

Ami még "szebb", most hogy fenn van az alap Squeeze a RIP cfdisk -jével készült partíciókat meg sem képes jeleníteni:
"FATAL ERROR: Bad primary partiton 1: Partition ends in the final partial cylinder"
A RIP cfdisk 2.19.1, a Squeeze 2.17.2 ... téboly.
Mi lenne ha több terabájtos szervert kellene felépítenem?
Ha a Debian telepítő particionálóját használom tele voltam lyukakkal. Amikor RIP -el csinálom szép és tiszta, a telepítésnél ugyan ezek a partíciók megint csak mindenféle 10-60K bájtos lyukakkal jelenik meg.
Mivel és hogyan particionáljak?
Most ez komoly? - cylindereket kell számolgatnom, vagy mi alapján készítsem?
"Terv":
sda1/sdb1 - ck. 10G elsődleges, bootolható rendszer
kiterjesztett terület:
sda5/sdb5 - ck. 4G logikai - swap
sda6/sdb6 - ck. 80G logikai - adatbázisoknak (MySQL)
sda7/sdb7 - ck. 400G logikai - home könyvtárak

Ennél egyszerűbbet nehéz lenne kitalálni. Tény kicsit hülyén hangzik a 4G swap de vigye kánya. Viszont az hogy mindenféle hibát dobál az zavar. Nem tudom, milyen gondokat okozhat később, amikor majd mondjuk javítani kell, vagy diszket cserélni a tükörben.
Érdekes hogy az "sfdisk -V" a 2-es kiterjesztett partícióra panaszkodik:
"Warning: partition 2 does not end at a cylinder boundary"

Ezt sem értem :( Semmi extrát nem csináltam a kiterjesztett partícióval, csak a cfdisk által javasolt méretekkel dolgoztam ...
A kiterjesztett partíció végét nem is tudom igazán pozicionálni.
A syslog nem mond erről semmit.
Most lehet hogy ez valami BIOS probléma?
Mivel particionáljak, hogy ne legyenek ilyen gyanús kis WARNING -ok és brutális FATAL -ok?
Javaslatok?

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

Na most annyit tettem, hogy a két utolsó partíciót töröltem mindkét diszken (sda6/sdb6 és sda7/sdb7). Amúgy sem kerültek még használtba - még csak az alapoknál tartok.
Most a Squeeze cfdiks/sfdisk NEM jelez hibát!
Na mivel particionáljak?
Visszaraktam (Squeeze -ből) a 80G adat partíciót (sda6/sdb6) - még minden rendben (cfdisk/sfdisk).
Újra bootoltam :( - még minden rendben leszámítva, hogy az md megrpbálta felállítani az md2 (ami a /dev/sda6 és /dev/sdb6) és nem sikerült neki, na bumm :)
Most a maradékot is kiosztottam, még mindig cfdisk -eddig jó - reboot.
Érdekes, még mindig csak az md2 -re panaszkodik az MD - és az md3?
Minden zöld! - sfdisk, cfdisk nem jelez semmi gondot, tök jó.
Most újra építem az md2 és az md3 -at, sőt, le is formázom őket!

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

No. Most minden zöld :D
Volt még egy apróság, az /etc/mdadm/mdadm.conf módosítani kellett az md2 és md3 bejegyzésénél az UUID -t és a nevet - persze azt már többé nem generálja újra.
Már csak azt nem értem, miért kellet ennyi fölösleges kört megfutnom?

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