Naplózó filerendszerek (journaling)

Sziasztok,

Olyanban kérném a véleményeteket, hogy web kiszolgálásra melyik a megfelelőbb fájlrendszer. Jelenleg ocfs2 (1.5.0) van a szervereken. Sajnos a ocfs nem egészen úgy működik ahogy kellene, vannak gyermek betegségei. Illetve a teljesítményével, se vagyunk megelégedve. Egyik nagyon zavaró hibája, hogy a nodeok közötti lockolások folyamatosan hibát dobálnak (DLM_BADARGS). Ezt a hibát elvileg javították a 2.6.29 kernelben, de kipróbálva ezt a szériát a teljesítménye majdnem a felére esett (hibás kernelel (2.6.28) 6 load a szervereken, javított kernelel 12-15 load + nagyobb i/o wait). A hibás kernel stabilitásban se a legjobb! A szervereken ubuntu van. A kérdésem az lenne, hogy ocfsnek milyen alternatívái vannak, amely produktív környezetbe használható. Én gfs/gfs2 néztem ki, de véleményt szeretnék kérni, hogy milyen alternatívák vannak, illetve ki milyen fájlrendszert javasol. A clusterben 5 node van és egy SAN tömbbe csatlakoznak FC-vel.

Válaszokat előre is köszönöm.

Üdv Mindenki!

Lenne egy nagy és megoldandó problémám.

Hálózaton van egy Samba server, amire több gép is csatlakozik. Az egyik gépről indítottak egy törlést véletlenül, amit megszakítottak.
Sajnos így is 348 file törölve lett.
A nagyobb gond az, hogy erről egy nappal később értesítettek, addigra viszont valaki dolgozott a szerverre, tehát a journal szerint a legrégebbi bejegyzés már a törlésnél egy nappal későbbi volt. Nem tudom, hogy lett-e ezalatt felülírva adat, ha igen, akkor mennyi.
Elkezdtem az adatok visszaállítását az ext3grep nevezetű programmal, de a gondom az, hogy a törölt fileok közül egyet sem állít vissza. A mappákat mind megtalálta, névvel együtt vissza is lehetett állítani őket. Ha inode-okra keresek, és ezeket elkezdem visszafejteni az ext3 grep-ben, akkor látom az elérési utakat, a file-okat, meg azok adatait (létrhozás, módosítás, törlés ideje, jogosultságok, stb.) de visszaállítani nem akar sikerülni.

Kérdésem az lenne, van-e valaki, aki használta már az ext3grep-et és ha igen, tud-e segíteni jótanáccsal?

(A kürt kft-s megoldások nem jók, mert igaz az adatok fontosak, de annyi pénzt sem áldoz rá az illetékes, hogy egy 500Gb-os vinyót keríthettem volna, hogy egy IMAGE-t csináljak a merevlemezről.)
Megjegyezném a szerverben 2db 500 Gb-os merevlemez van tükörben. ezek közül most az egyiket kivettem, azon dolgozok. a másik maradt a gépben féllábúként. a sérült partíció le van csatolva.

Köszi előre is.
Saphran3k

Sziasztok!

Bocs a hulye megfogalmazasert, de eddig ilyet nem lattam. Felhasznalo konyvtaraban van egy file, amit nem tudok sehogy letorolni:

ls -al
?--------- ? ? ? ? ? courierima0acl
-rwxrwxr-x 1 zsolt zsolt 43 2008-07-09 12:23 courierimapacl
mc-ben pirossal latszik, a kerdes csak annyi, hogy ilyen esetben mi a megoldas hogy megis le lehessen torolni a courierima0acl filet?

Debian Sarge, kernel 2.6.20.3. 2 db hdd mirorrban

Minden segitseget elore is koszonok

Hali!

A kérdésem az lenne, hogy állnak linux alatti fájlrendszerek a transzparens tömörítéssel. Dúrtam egy kicsit a google-t a man oldalakat. Nem túl sokra jutottam. Viszont a wikipédián találtam egy bejegyzést, hogy a reiserfs http://en.wikipedia.org/wiki/ReiserFS tudja. De is csak az adatlapján áll és semmi nincs róla részletesen.
1. Egyáltalán van-e linux alatt olyan fájlrendszer ami tudja ezt a funkciót stabilan.
2. Ha megy a dolog reiser alatt akkor hogyan tudom kezelni?

Lemerevedett a Linuxom, majd újraindításkor a grub prompt jött elő.
live disk bootoláskor az írja:
Buffer I/O error on devive sdb4, logical block 8
Buffer I/O error on devive sdb4, logical block 9
Buffer I/O error on devive sdb4, logical block 10
Buffer I/O error on devive sdb4, logical block 11
az fsck az mondja " Attempt to read block from file system reulted in short read while trying to open /dev/sdb4
Could be a zero length partition.
A gparted látja a partíció hosszát és azt is, hogy ext3, de üresnek érzékeli. Van-e ötletetek, mivel tudnám visszaállítani?

Kezdem az elejen:
P2-es gep, sajat 2.6-os kernel, etch, ext2. Kozben a gep P4-es lett, wincsi nagyobb (most 8G), KDE lett IceWM helyett (kdm-mel) etch maradt, de az ext2 kapott egy -j attributumot :) (keletkezett a fokonyvtarban egy /.journal file is).

Lenny-t kiirtam DVD-re, atadtam anyamnak, berakta a gepebe es nekialltam apt-get dist-upgrade a frissitesnek. A fontosabb dolgok:
- kernel
- X.org
- KDE
frissultek. Es most jon a pofancsapas (azt leszamitva, hoyg a relvnc-bol szarmazo vnc.so meghalasztja az xorg-ot, ha kapcsolodni probalok, etch-ben pedig mukodott):
Ujrainditas utan kulonfele file-ok tartalmat felulirja. Jellemzoen az /usr/lib alatti file-ok, libfont.so es hasonlok. Nem tudom, hogy mi csinalja, nem tudom, hoyg hogyan (apt-get intall --reinstall csomag vagy ujrainditas utan a mar latott/felulirt filet lecserelni egy elmentettre) es miert mindig mas filet.

Csak tippelek, hogy a journal bekapcoslasa nem okozott gondot etch-nel, lennyt meg fejbevagta. A fileokba igazi szemet kerul, vegyesen binaris es text adatok, szoval olyan, mintha nem egy file tartalmat masolna bele, hanem nyers lemeztartalmat. Ez miatt is a jorunalra gondolok. Talalkozott mar valaki hasonloval?
(Kivansagra kesobb feltolthetem valahova az egyik felulirt filet, de majd csak este/holnap)

Sziasztok,

Az a problémám, hogy nem csatolódik fel a hdd1 :(. Az történt, hogy a gépben volt ez a hdd. Reboot utan nem csatolta fel.
Manuálisan:

mount -t ext3 /dev/hdd1 /mnt:

mount: wrong fs type, bad option, bad superblock on /dev/hdd1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

mount -t reiserfs /dev/hdd1 /mnt:

mount: wrong fs type, bad option, bad superblock on /dev/hdd1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

dmesg:

VFS: Can't find ext3 filesystem on dev hdd1.
attempt to access beyond end of device
hdd1: rw=0, want=130, limit=62
ReiserFS: hdd1: warning: sh-2006: read_super_block: bread failed (dev hdd1, block 64, size 1024)
ReiserFS: hdd1: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on hdd1

Ugrott az fs?

Csaba

Hello!

Most, hogy ennyi hir jon a btrfs fejleszteserol es az ext4 kernelbeolvasztasarol, en is elgondolkodtam ezen a fajlrendszer dolgon. Az ext4 jol hangzik, de talan tulsagosan uj meg. A jfs-rol jokat olvastam, es meg van egy rakas, amiket nem is tudok hova tenni. Ugy gondolom, kiprobalnek valami mast az ext-eken kivul az uj rendszeremhez, a jfs-t, vagy barmi mast ami jobbnak tunik majd. Szoval velemenyeket kernek fajlrendszerekkel kapcsolatban, ill. azzal, hogy ez a jfs jo otlet-e szerintetek. Esetleg van jobb is? Valami ertelmes link, ahol osszehasonlitjak ezeket (pro es kontrakkal esetleg), es nem elsosorban az ext4-rol szol (abbol van eleg).

Kosz a segitseget es a velemenyeket.

Talán sok embernek triviális, de nekem gondot okoz.

Segítséget kérek!

Egy ismerős kért meg, (most éppen nem fér net közelébe) nézzek utána megoldható e a dolog adatvesztés nélkül.

A partició felosztása.

root = etx3
home =reiserfs (ezt akarja XFS-re konvertálni)

a partició 120GB ebből kb 90GB használt. archiválás /pill nem megoldható.

megoldható valahogy a dolog? hogyan? liveCD?

előre is köszönöm a válaszokat.

dombi1976

Sziasztok!

Tudom már megint egy újabb ilyen idióta kérdező:)

A következő lenne a kérdésem:
Adott egy rendszerünk amin jelenleg minden ext3 alatt van. Pár hónapja elburult fsck közben az egyik partíció. Elég kényes programrendszer lett oda majdnem, lényegében majdnem teljesen.
A mostani karbantartás alatt felvetődött, hogy lecseréljük alatta a fájlrendszert.
A fájlrendszeren a következő szempontok alapján kéne döntenem:
- Sok 53 byte-os állomány, amik néha ha feltorlódnak órák alatt akár milliós nagyságrendre is nőhetnek és sajnos ez egy mappában.
- Rendszeresen jönnek létre 300->4,5G állományok is (naponta két alkalommal)
- A rajta létrejövő adatokat sajnos elég gyakorta (percenként) nyálazza át a find (ez főképp akkor gond, ha az apró fájlok feltorlódnak)
- Elég jelentős (cc 300) kliens használja majdnem mindig egyidejűleg
- Van egy mappaszerkezet amiben 53 byte -> 120-150k méretig vannak átlagosan fájlok, 90 napig. Ezek száma 150ezertől akár 500ezer is lehet. (Nem pontosan egy mappában, hanem 47-ben szétosztva, de nem egyenletesen) Ezen szerkezetnek a feldolgozása elég erőteljes IO wait létrehozását szokta jelenteni.

Ami még probléma, hogy mindenképp kernelfordítás lesz a fájlrendszer csere előtt, mivel a jelenleg futó kernel csak ext3 támogatást tartalmaz. (Nem, nem tudom letölteni hozzá a megfelelő modulokat, még mielőtt megkérdezné valaki.)

A rendszer folyamatosan működik, esetleg rendkívüli okok miatt áll le évközben. Mostantól január 5.-éig tudok változtatni, amennyiben akarok.

Amire gondoltam eddig, az az xfs és a reiserfs. Csak nem tudok határozni. Mindegyikre van pro és kontra. Azonban mivel kritikus helyen működik, nem szeretném ha arra kelnék éjszaka közepén, hogy elborult a rendszer. (Hideg tartalék rendszer van, rendszeresen mentve is van szalagra)

A válaszokat előre is köszönöm!

Üdv.: Árpád