crash után quota ellenőrzés 1 óra hosszáig

Linux-haladó

A gondom a következő:
volt egy olyan áramszünetünk, amelynek hosszát gyengélkedő UPS-ünk csak néhány percig tudta áthidalni, amelynek következtében Frugalware Linux alapú szerverünk leállt. Újraindítás után a linux elindult, az fsck az 1.5 Tb-os partíciót egy pillanat alatt átnézte, azt mondta, hogy clean, minden ok. Ezután jött a feketeleves: elindult a quotacheck, ami újraépítette a kvótafájlokat: több, mint egy óra hosszáig meg sem mozdult a gép; se tűzfal, se internet, se levelezés, se semmi.
Rendszergazdánk azt mondja, hogy ez frugal-ban is meg ubuntu/debian-ban is így van, indításkor a rendszer létrehoz egy fájlt, leállításkor letörli, és ha újabb induláskor még mindig létezik, akkor crash volt, és meghívódik a quotacheck.
Egyszerűen nem tudom elhinni, hogy ha egy, a miénknél sokkal fontosabb gép valamilyen hiba miatt megáll, akkor indítás után csak percekkel/órákkal később válik használhatóvá.
A kérdéseim:
1. tényleg így van-e minden oprendszernél, illetve tényleg szükséges ilyen leállás után mindenképpen meghívni a quotachecket?
2. ha meg muszáj, akkor nem lehetséges az, hogy ez a kvótaellenőrzés a háttérben történjen meg a már normálisan működő funkciók mellett?
Köszi a segítséget.
Tamás

  • 1174 megtekintés

( lacika v | 2007. 10. 18., cs – 21:15 )

A quotacheck minden bootkor lefut. Nem kaptál téves infót a rendszergazdádtól.
Vannak olyan rendszerek, ahol "csak" a POST eltart egy-két óráig.
Ha nagyon fontos a rendszer, akkor az clusterben van és nem helyi diszkeken van az adat, hanem valami storage -on.
A quotacheck nem tud lefutni (vagy legalább nyüsszög erősen), ha a partíció rw -ben van felcsatolva.
Meg ha bele gondolsz, ha egy partíció rw -ben van csatolva, nagy I/O mellett (de kicsi is elég) nem tudja a rendszer a pontos quotat meghatározni/ellenőrizni, mert változik a tartalom.

--
http://laszlo.co.hu/

( sibidiba | 2007. 10. 18., cs – 23:59 )

A quota fájlrendszer-specifikusan van implementálva. Gondolom ext2/3 volt a partíción.

Az ext filerendszerek nem támogatják natívan a quotát, az kernelspaceben/userspaceben valósul meg.
Pont emiatt van külön quotacheck, és pont a hasonló esetek miatt nem feltétlenül ajánlott ext-et használni nagy és quotázott diszkeken.

Ajánlom helyette az XFS-t.

--
The Net is indeed vast and infinite...
http://gablog.eu

( ltamas | 2007. 10. 19., p – 13:04 )

Sajnos az XFS-re átállás jelenleg nem lehetséges, maradnunk kell az EXT3-nál. A szünetmentes táp akkucseréje is be van ütemezve, ennek ellenére a dolog tovább idegesít. Mivel a gép maga a tűzfal, semmi esetre sem elfogadható, hogy mondjuk egy napközbeni valamilyen leállás miatt közel másfél órára megálljon a rendszer. Kérdés az, hogy egy ilyen crash után mennyire válnak a kvótafájlok inkonzisztenssé, vagyis ha én kiveszem a quotacheck megállás utáni automatikus indítását, akkor mennyire fog hamis adatokkal dolgozni a kvótarendszer? (Esetleg azt megcsináltatnám a rendszergazdával, hogy ilyen esetben éjjel történjen egy újraindulás, és akkor csinálja meg a rendszer az újraellenőrzést.)

Nomostan fájlszerver vagy tűzfal?! A két funkció egy gépre rakása sem biztonsági, sem pedig performancia szempontból nem fogadható el.

Ha jól veszem ki a szavaidból, akkor a quota nem vérremenően fontos, mi van akkor, ha kihajítod, és éjjelente futtatsz egy scriptet, ami per user megmondja, hogy ki, mennyi diszkterületet fogyaszt, és e-mailben szól, ha valaki túllépte a számára megengedett mértéket.

Mint fentebb írták, crash után mindenképp helyre kell rakni a quotafájlokat, ami időt, sok user, mégtöbb fájlja esetén sok-sok időt vesz igénybe. Ennek időigénye független attól, hogy az fs konzisztenciája milyen gyorsan hozható helyre.

Lehetne itt vitákat folytatni az első kérdéseddel kapcsolatosan, lehet, hogy igazad is van, de ami most van, az adott.
Az éjjelente ellenőrzés ötlettel az a gond, hogy nem nem gátolja meg azt, hogy mondjuk valaki nappal feltegyen 200 Gb adatot az ő 1 Gigás tárhelyére.
Én azon gondolkodom, hogy ha a RAM-ban is vannak a kvótázáshoz szükséges információk, akkor is csak elmenti azokat valamennyi időnként a processzor a fájlrendszerbe. Ha most ezután bekövetkezik az, aminek nem kellene bekövetkeznie, akkor csak a két időköz között módosított fájlok foglalási adataiban különbözik az utolsó mentett információ a ténylegestől.
Például percenként kiírja a kernel a kvótainformációkat a winchesterre. Ha a crash előtt fél perccel valaki letörölt egy 50 megás fájlt a tárhelyéről, akkor a ramban lecsökken a foglalása 50 megával. A leállás miatt tehát a kvótafájlok 50 megával többet tartalmaznak emberünknél, mint amennyi adata valójában van neki. Tehát hiába van gigás kvótája, 950 mega után következik be az, aminek be kell következnie. De ez az egész nem lenne számomra tragikus, legfeljebb emberünk számára. Evvel ellentétben ha emberünk közben írt a tárhelyre 80 megát, akkor neki leállás után 80 megával több lesz a foglalása, mint amennyiről a kvótarendszer tud. Ez számomra rövid távon szintén nem lenne tragikus. Egy ilyen megállás után éjjel újraindulna a rendszer, akkor lefutna a quotacheck, és rendbetenné a dolgokat. Nappal lenne egy kis inkonzisztencia, éjjel meg egy másfél órás leállás. Mindkettő elviselhetőbb, mint egy nappali másfél órás üzemszünet.
A kérdés az, hogy így működik-e a dolog, ahogy én elképzeltem, vagy mondjuk a kvótarendszer rendszerinduláskor kiolvassa a kvótafájlokat, minden információt a RAM-ban tart, és csak leálláskor/quotaoff-kor írja vissza a kvótafájlokba. Ekkor egy crash mondjuk 3 heti információt is elveszíthet, ekkor jogos, hogy mindenképpen kell a quotacheck. (Bár ekkor meg szerintem azt a lehetőséget fogom felvetni, hogy teljesen kapcsoljuk ki a kvótát az éjjeli újraindulásig.)

Az xfs-re való átállást UPS akkucsere nélkül nem is javaslom, nehogy váratlan áramszünetnek legyen kitéve a gép (bár gondolom nut-ot azért használtok).
Aki itt felkapja a fejét, hogy miért nem jó egy journaling filerendszernek, ha hirtelen kihúzzák alóla a sámlit, annak ajánlom a következő linket, ahol egy bizonyos Theodore Ts'o nevű ürge magyarázza el, hogy miért is teljesen más ebből a szempontból az ext3 a resiserfs-hez és az xfs-hez képest: LINK. Azt nem tudom, hogy a jfs hogy csinálja a naplózást.

Szerintem ha rendes quota kell és adatbiztonság, akkor ki kell várni újraindításkor az időt. És ha az idő pedig annyira fontos, akkor pedig kell legyen pénz egy jó UPS-re.

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

A szemét, részrehajló, tehetségtelen Theodore Ts'o arról hazudozik, hogy mit mondtak neki az SGI mérnökök?
Ha nincs ínyedre a dolog, akkor elvégezheted azt az egyszrű próbát, amit az idézett thread-ben ajánlanak:
1. Telepíts egy gépet xfs-sel, resiser-rel és ext3-mal.
2. Miközben a gép buzgó fájlműveletekkel van elfoglalva húzd ki a dugót.
3. Ellenőrizd le, hogy mit csináltál.
"simple as a pie"

Utána lehet fikázni.

Tudom, tudom: az NTFS, a HFS, meg az UFS az sokkal királyabb és nem olyan ciki a gépen futtatni, mert nem csúfolnak ki a BSD-s és a Maces haverok.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nekem is voltak rossz tapasztalataim a reiserrel. Ezt a thread-et valahogy kihagytam. Végül is mindenki azt használ, amit akar. Ha trey reiser-rel akarja mulattatni magát, akkor az az ő dolga.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ha adottságként fogjuk fel a fw+fs funkcionalitást egy szerveren, akkor fogadd el adottságként azt, hogy ext[23]fs esetén a quotainfók egy összedőlést követően ennyi idő alatt épülnek újra.

Persze lehetne a quota-hoz tartozó initscripteket módosítani, meg hozzá azt is megoldani, hogy crash után az adott fs-t quota opció nélkül csatolja fel, de ez randa gányolás (mint ahogy a funkciók keverése is, de az más tészta...).

A quota-információban nincs "három hetes", csak nearly up-to-date, minden mást el kell felejteni, mert az nem quotainfó, hanem történelem :-) Azt a megoldást, amit írtál, megpróbálhatod implementálni, de fölösleges, xfs-nél megoldott a dolog.

( Replaced | 2007. 10. 19., p – 18:28 )

> Frugalware Linux alapú szerverünk

problem located

--
Bow down and admit defeat. | Old, weak and obsolete.

Csak nem azt akarod mondani, hogy az UFS és/vagy a HFS az egy gyorsabban kvótázó naplózó filerendszer?

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Hát ez az. Persze ha egy BSD fant kérdezel, az azt fogja mondani, hogy: naplózás szakesz, soft update rulez.
Meg használj VMS-t, meg AIX-et mainframe-en.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Engedd meg, hogy exhumáljam magam. Már túl rég flameltem és elkapott a kisértés.
Az XFS tényleg egy robosztus filerendszer egyébként. Én is használok XFS-t SGI/IRIX-en. Nincsenek vele problémák.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( handler | 2007. 10. 19., p – 19:51 )

Ajanlom figyelmedbe az XFS fajlrendszert, amely a quota informaciokat is az fs journal-ba irja. Bovebben: xfs_quota manual.

"The XFS quota system differs to that of other filesystems in a number of ways. Most importantly, XFS considers quota information as filesystem metadata and uses journaling to provide a higher level guarantee of consistency."

( csonti | 2007. 10. 19., p – 20:06 )

lehet, hogy vicces leszek, de meg lehet kerülni ezt a kvótázást egy szkripttel, mely a du parancs segítségével lekérdezi a felhasználók anyagait és a renitenseknek emilt küld vagy le is tilthat. Berak egy crontab-ba és kész. :))