Sziasztok!
Az otthoni NAS-omban van 3 db diszk szoftveres RAID5-ben. Teljesen jól működik hónapok óta, de időnként számomra ismeretlen ok miatt újraszinkronizálja magát.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdd1[3] sdc1[1] sda1[0]
2930269184 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
[===============>.....] check = 77.1% (1130650424/1465134592) finish=138.4min speed=40274K/sec
unused devices:
Mi ennek az oka? Talán ez?
cat /etc/cron.d/raid-check
# Run system wide raid-check once a week on Sunday at 1am by default
0 1 * * Sun root /usr/sbin/raid-check
Mi történne, ha kikapcsolnám??? Vagy esetleg havira állítanám?
Előre is köszi a választ!
- 4996 megtekintés
Hozzászólások
Ez így van, hagyd úgy ahogy van, hidd el, akik kitalálták ezt jobban értenek az MD-hez, mint mi.
- A hozzászóláshoz be kell jelentkezni
Szia,
ez egy konzisztencia ellenorzes, aminek a haszna ugye egyertelmu; azonban ez nem resync.
Az viszont totálisan biztos, hogy erre az időre pl rsync, etc hasznalata totalisan ellenjavalt, mert pl. mar talalkoztam olyannal, hogy a kthreadd -t elegansan kihajította a kernel, mert ugye timeoutolt a lassu disk subsystem miatt. Ezzel rogton elmaszott a 15T-s raid5 es a rajta levo xfs is elbotlott. (Ez egy backup szerver). Az adott esetben sysrq -hoz kellett folyamodni, mert ugye a pdflush sem tudott lefutni, es a reboot sikertelen volt, csakugy, mint a remount.
Tovabbi kellemessege volt a dolognak, hogy a sok kismeretu file miatt xfs check sem tudott lefutni, mert az meg beleszaladt az oomkillerbe....:) Azota xfs -t sok kis fajl ala nem pakolunk...
- A hozzászóláshoz be kell jelentkezni
A resync min-max sebességét lehet állítani, alapból se túl magas, de visszább lehet venni, legalább a minimumot. Akkor _elvileg_ bármit csinálhatsz a gépen. Pl. mi is mentünk, rsync-kel is, millónyi kis fájlt meg nagyokat is, symlinkes mentéseket csinál, jellemzően rémsok linket csinál inkább, és bírja.
Ha az oomkillerbe szaladt bele, akkor meg nem a sok kis file volt a baj, hanem a kevés memória, nem? Jó, gondolom a sok kis fájl miatt kellett neki a sok memória.
- A hozzászóláshoz be kell jelentkezni
oomkiller=Igen, tul sok kis fajl volt; 4G ram +2 G swap nem volt eleg. A vegen 9G swappal probaltuk, de az is keves volt.
resync sebesseg: Eddig sosem volt vele problema default beallitasban (es en hiszek abban, hogy a debian csomagkarbantartok nem hulyesegbol lottek be azt a defaultot, ami be van love), de a check + több konkurrens rsync processz eleg nagy pofon volt.
Amugy inkabb diszkhibara tippelunk, de eddig semmi nem igazolta.
Ami inkabb erdekelne, hogy a kernel ahelyett, hogy a userspace -ben futo rsync -eket gyilkolta ki (ami raadasul nem is a root neveben futott), milyen affinitasbol a kthreadd -t olte meg, mint kritikus rendszerfolyamatot (aminek kapcsan az ezt a raidet erinto osszes folyamat meg is allt, ps szerint D statuszban, ami nem killelheto (rsync, raid check, etc.)).
- A hozzászóláshoz be kell jelentkezni
Orosz rulettet játszottak, és a kthreadd volt a peches :)
- A hozzászóláshoz be kell jelentkezni
Ok, de most telleg, miert lehet ez?
1153 folyamat lehetett volna, amit kinyirhatna, de o nem ezt tette.
A kthreadd valoban nem valaszolt 120sec-ig, de a kapcsolodo folyamatok "voltak a hibasak", nem a kthreadd. Igy viszont a kernel tokonszurta sajat magat, ami erosen vicc kategoria.
Elkepzeleseim szerint child/kapcsolodo folyamatokat kellett volna kinyirnia, es igen, ha ez nem megoldas, akkor johetnek a rendszerfolyamatok.
- A hozzászóláshoz be kell jelentkezni
Szerintem kikapcsolható, de ha fontosak az adatok, akkor nem árt.
Ha kikapcsolod és nincs disk hiba, áramszünet és hasonlók, akkor valószínűleg a kikapcsolásból nem származik majd hátrányod.
Ha havi 1-re állítod abból nem lesz gond. Az általam használt distroban is úgy van, hogy defaultban 1x fut havonta:
#
# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft
# distributed under the terms of the Artistic Licence 2.0
#
# By default, run at 00:57 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet
- A hozzászóláshoz be kell jelentkezni
meggyőztetek, hagyom a heti futást, de átraktam hétfőre, mert akkor kevésbé zavar, mivel nem vagyok otthon
- A hozzászóláshoz be kell jelentkezni