bgfsck emulacio otlet

A problema az, hogy egy csomo helyen muszaj ext2/3 fajlrendszert hasznalnom, neha riaszto meretekben.
Ezen esetekben ugye az idonkent bekovetkezo (180 nap) fsck a bootot megallithatja akar fel napra is.

Az alabbi vazlatot talatam ki ennek a kikerulesere (RFC :) ):

1. csinalunk egy RW snapshotot az LV-rol (LV_SNAP).
2. megallitjuk az alkalmazasokat akik piszkaljak a fajlrendszert
3. umountoljuk az eredeti LV-t (LV_ORIG)
4. mountoljuk az LV_SNAP-ot az LV_ORIG mount pontjara
5. elinditjuk az alkalmazasokat amiket megallitottunk
6. lefuttatjuk az fsck-t az LV_ORIG-on (-f -y ???)
7. felmountoljuk valahova az LV_ORIG-ot
8. mount -o remount,ro LV_SNAP
9. rsync vagy valami modon szinkronba hozzuk az LV_ORIG-ot az LV_SNAP-pel
10. alkalmazasok leallitanak
11. LV_SNAP, LV_ORIG umount
12. LV_ORIG mount
13. alkalmazasok elindittatnak
14. LV_SNAP torlese.

Otleteket, ellenveteseket szivesen latok.
Az nem jatszik, hogy hasznaljak masik fajlrendszert. A teljes spektrumot megjartam mar :-D

Kepzelt hasznok:
1. nem bootkor tortenik mindez a sok szarsag (tervezheto).
2. kicsi az alkalmazasok downtime-ja.
3. tulajdonkeppen akarmilyen fajlrendszerrel mukodhet.

Elore lathato hatranyok/ketsegek:
1. BONYOLULT kovetkezeskeppen torekeny.
2. micsinalok, ha vegzetes hibat talalok fsck kozben? hagyom -y aztan lesz ami lesz?
3. Nem vagyok biztos, hogy minden VG-mben van eleg hely a dolog kialakitasahoz.
4. Milyen hosszu a read-only fazis? Ez komplett no-go lehet bizonyos gepeken.
5. rsync a megfelelo eszkoz? I/O es CPU intenziv.
6. ...
7. ...

Nagyon szeretnek mar egy mukodo, megbizhato, kozepes teljesitmenyu, FSCK-mentes skalazodo fajlrendszert.

Nagyon.

( LGee | 2007. 10. 02., k – 15:00 )

Ki kell kapcsolni az fsck-t, es elore tervezett karbantartasok kereteben rendszeres idokozonkent manualisan ellenorizni a filerendszereket. Mar ha valami produktiv dologrol van szo.

Az nem gyorsabb, hogy ha egyszer már úgyis klónozod a partíciót, akkor leformázod az originalt majd rsync-el visszatolod a fájlokat? Mert akkor jó esélyjel nem lesz hiba a fájlrendszerben (fsck megoldva), csak mivel ez sokáig tart, 2 rsync kellene. És 2 klón, mivel a futó programok alá nem engedhetsz rsync-t. Bár ha a formázás elég gyors, akkor addig talán kibírható a vinyót használó progik futattásának hiánya.

nem tudom, hogyan usznam meg ezt helyigenyileg.
A snapshot elrakja azokat a blokkokat amik megvaltoznak az eredetiben.
Egy mkfs/ujramasolas eseten ez kiraly mennyiseg is lehet :)

A formazas gyors lehet, de az rsync 5-600G vagy 1-2T adat eseten semmikeppen nem poen. Rettento sokaig el tud pocsolni vele.
Nem beszelve az irgalmatlan I/O mennyisegrol.

Azalatt a szerver olyan lesz mint egy terhes csiga.

Az en otletem annyival elorebb van, hogy a fajlok az eredeti fajlrendszeren ott vannak. Csak a megvaltozott fajlokkal kell foglalkozni az rsyncnek.

Szia Zahy,

long time no see.

- advfs: sajnos valoban fajna Linuxon elinditani :-D Jobb platformot erdemel az ennel.
- Veritas vxfs: Sajnos penzes, "unknown entity"

A tobbi jfs, xfs, reiserfs fajlrendszerekkel is az volt a baj, hogy a belso terheleses teszteken bizonyos szituaciokban megbuktak. Eddig az ext3 volt az egyeduli joszag ami mindent tulelt amit elvartunk tole.
Nem vagyok meggyozodve rola, hogy egy ujabb ismeretlen bevonasa es tesztelese (ido/penz) megeri.

Arrol nem beszelve, hogy a HP-UX-os idombol valami riaszto szamok remlenek fel a cucc araval kapcsolatban :)
Nekem meg kellene belole vagy 10-15 peldany.
Szerk.: Meg most megnezve a termek weboldalat, sajnos elegge korlatozott a tamogatott "Linuxok" listaja. Pl Debian nincs benne :-D

A teny, hogy nem tudsz a hibarol, nem szunteti meg a hibat :)

Sajnos volt mar hibas fajlrendszerem minden lathato ok nelkul is. S volt mar rejtozkodo memoria hibabol eredo fajlrendszer hibam is.
Csak gepek szamanak kerdese milyen hamar futsz bele valami ilyesmibe.

S nem arrol van szo, hogy kizarolag a 180 naponta bekovetkezo fsck faj. A bootot megallito barmilyen okbol bekovetkezo fsck faj, mert orakra megall a boot tole.
Ezt kellene elkerulni. Akar ugy, hogy havonta menet kozben a fent leirt tancot eltancoltatom a geppel. S akkor legalabb lesz egy ismert allapotu fajlrendszerem.

Koncepció jónak látszik, az agájaid is jogosak. rsync jó választás mivel mást nem tudok ami megfelelhetne :)
Biztonsági menteni? A képből hiányzik (mikor/hogyan).

Ha az fsck nem talál hibát (vagyis nem modosít) akkor gondolom elég, ha átírod legközelebbi checket mátol 180 napra.

A mentesek azok ettol a kupac dologtol fuggetlenul mennek.
Azok is rsync-kel :)

az a 180 nap az resetelodik amikor lefut az fsck. De igazabol, ha ezt beuzemelem, letsztelem, az egyetlen dolog ami csinalni fog fsck-t az ez a script lesz.

Az fstabban szepen kikapcsolom az erintett kotetekre az automata fsck-t.

http://en.wikipedia.org/wiki/Ext3cow
http://sourcefrog.net/projects/snapfs/
ilyesféle dolog kéne nekd.

szet nezhetsz fuse tájékán elég okos dolgok vannak.

rsync -el az a baj, hogy az összes filet meg kell néznie modosult e az pedig idő lehet.
ionotify vel meg teljes filrendszert elég nehézkes megfigyelni, talán egy kprobe segíthet.
Le kell tárolni az összes írásra megnyitott file listáját (lsof?), és az eztán megnyitottakét, ,hogy csak azt probáld syncelni.

Egy virtulis filerendszer lenne a legjobb ami ro -ként kezeli az egyik snpshotot, változások listáját meg elmenti valahová (nem block szinten, mint az lvm), aztán megigéred neki egy másik filerendszeren (fsckzott) ugyan az van , oda kiiaratni változásokat, és felmountolni..
Egy erre a célra is alkalmas filerendszeren filózok régóta a saját distromba, ha elkeszül bekerül :) (v2 feuture lesz, egyenlőre munkaneve overlayfs , unionfs+tmpfs kiváltésa v1 célja biz. szituációkban tehát v1 ramba, ment csak..)

szerk: ,ja sync kiadása sem árt esetedben.

( pexik | 2007. 10. 05., p – 20:51 )

Még kezdő vagyok, ha nem hülyeség, talán ötletnek jó, amit írok. Ha jól veszem ki, akkor neked egy nagy rendszered van, és talán használsz terhelés elosztást is.
Most tanulmányozom az iptables-t, és ott láttam round-robin néven. Ebben az esetben csak az egyik gép állna le, és az fsck elvégezhető lenne tervezetten, és utána lehetne szinkronizálni újból.

( pexik | 2007. 10. 08., h – 15:36 )

Ilyen felépítést sejtettem, és arra gondolok, hogy ha van több gép, mindegyik mást/másokat szolgáltat, esetleg páronként összevonnád, az összevontakat dupláznád meg, akkor kb szolgáltatásonként fele terhelés, de dupla mennyiségű szolgáltatás, a terhelés kb azonos lenne, és a gépek száma nem változna. Úgyis akartál egy spnashotot, akkor van némi területed erre a célra, további bővítésnél a vinyó és a memória talán nem olyan drága, mint egy teljes gép.

huh... Azert ez ennel egy cseppet bonyolultabb :)

Kezdve onnan, hogy a snapshot az kb 10%-nyi teruletet foglal nalam, az eredetihez kepest.
A tartalom ezeken a szervereken 200-700GB. Nem annyira szeretnem ezt mindet duplazni :)

a "paronkent osszevonas" az jo otlet leirva, de _nagyon_ sok munka, nagyon nagy kockazat, egy fizetos, termelesi statuszu szolgaltatason.
S valoszinuleg joval kockazatosabb mint azt gondolom most igy elso ranezesre.