Kérdések Linuxos naplózó fájlrendszerekről

jfs elég furcsa egy jószág. régóta használom, de nem igazán válik be, nem tudja magát normálisan megjavítani vmi deadlock után. Ilyenkor, sajnos reset gomb, minthogy magic-sysrq sem működött, úgyhogy elveszett a teljes etc-m tartalma(hogy miért csak az ?). Ezt lost+foundból kellett visszaállítani. Ellenben az XFS-t szerverekre szoktam rakni, nem nagy terhelésű, úgyhogy nemtudom, hogy olyan környezetben hogy viselkedik, viszont a buta-user-power-off-ot azt eléggé bírja. Ilyenkor álltalában az ext3-mal van gond a gépeken. Egyszer még régen mdk-n(most már mandriva) volt egy olyan élményem, hogy a kernel nem szerette ext3-mat(amire ugye rá volt installálva, ez egy gyári kernel volt, nem saját-forgatott) és aztmondta, hogy csókolom. Majdnem mindenem elveszett a root-ról. Még szerencse, hogy daraboltam: /, /home, /usr, / var külön partíción. Akkor talán csak a /home volt más részen, így az megmenekült, ami végül is fontos volt. Én XFS-t ajánlani tudom csak, és végülis, ha nincs áramszünet, meg ilyesmi, akkor a jfs sem rossz választás.

Peepy

Kiegészítésként:
- Ext3-t és reiser-t nem csak növelni, hanem csökkenteni is lehet
- Ext3-nál a journal különböző módokban lehet:

data=journal / data=ordered / data=writeback
Specifies the journalling mode for file data. Metadata is always journaled. To use modes other than ordered on the root file system, pass the mode to the kernel as boot parameter, e.g. rootflags=data=journal.

journal
All data is committed into the journal prior to being written into the main file system.

ordered
This is the default mode. All data is forced directly out to the main file system prior to its metadata being committed to the journal.

writeback
Data ordering is not preserved - data may be written into the main file system after its metadata has been committed to the journal. This is rumoured to be the highest throughput option. It guarantees internal file system integrity, however it can allow old data to appear in files after a crash and journal recovery.

Hallkan megjegyzem, hogy a reiser3 integritásvédelme megegyezik az ext3 "writeback" üzemmódjával, de a teszteknél ezt el szokták felejteni.

A SoftUpdates-el egy baj van: míg egy korrekt naplózó fájlrendszer egy crash után néhány másodperc alatt magához tér, és a teljesítménye ugyan olyan marad, mint előtte volt, addig a SoftUpdates tudtommal órákig molyol a diszken, jelentős performancia-degradációt okozva. Az rendben van, hogy legalább az fsck-t nem kell kivárni, de azért ez mégsem ugyan az.

- Undelete valóban nincs ext3-nál.
- Lehet törölhetetlen/módosíthatatlan fájlt létrehozni ext3-on, sőt lehet append-only fájlt is létrehozni. (man chattr, -a illetve -i opciók). Ehhez nem kell az EA.

Akkor a válaszok sorban, legjobb tudomásom szerint (tehát nem feltétlen a valóságnak megfelelően :) ):
- quota: elvileg független a fájlrendszertől, gyakorlatilag bizonyos interface-eket biztosítania kell a fájlrendszernek, hogy működjön. Reiser3-ra default kernellel állítólag nem működik, kell hozzá valami patch a namesys-től, de akkor is instabil. Én személy szerint nem próbáltam, de komoly figyelmeztetés van a gentoo.org-on ezzel kapcsolatban.
- ACL/Security Label: Reiser3-on amennyire tudom nincs ACL, és a security label is felejtős. A többin van, bár a legrégebbi, és talán legkiforrottabb implementáció az ext3-é (mármint Linuxon).
- Fájlrendszer átméretezés: ext3 és reiser megy, de csak offline. XFS-t és JFS-t tudtommal nem lehet átméretezni. Némi megkötés van ext3-nál és reiser-nél is, a partíció kezdetét nem tudod módosítani, csak a végét.
- Snapshot: ezt LVM-ből tudja a linux, nem kell hozzá fájlrendszer támogatás. Ráadásul tud olyat is, hogy csak a deltát tárolja a snapshot és az eredeti között, így egy kis forgalmú időszakban kevesebb, mint 20% elég a teljes snapshot lementéséhez. Nyomsz egy syncet, egy snapshot-ot, utána pedig a fsck-t a snapshot-on, hogy a sync után keletkezett, nem konzisztens bejegyzéseket visszagörgesd. Ez ugye journalos fájlrendszeren semmi idő alatt megvan (a legtöbb a mount közben megcsinálja). Utána fel tudod mountolni a snapshotot, vagy ki tudod írni, vagy azt csinálsz vele, amit akarsz.

[quote:bb3a02de33="Adi"]Pl. elhasalni nagyobb terhelésnél, MySQL alatt? :roll:

Ami azt illeti, erről csak olvastam, itt fut ugyan mysql, de nem veszett nagy terheléssel, viszont gyakoribb probléma az ostoba user, uh. még terhelés mellett is ezt választanám...

[quote:088a65ee20="Zahy"]
van-e olyan, hogy törölhetetlen/módosíthatatlan fájl (UFS-en ez az EA-tól függetlenül létező valami, ezért kérdezem külön)

Ext2 és Ext3 fájlrendszerek esetén van néhány plussz kiterjesztés, ami lehetővé teszi a szokásos chmod jogokon kívül további jogok definiálását. Ezek a további jogok globálisak, vagyis a rendszergazdára (root) is vonatkoznak. Ezeket a jogokat a chattr paranccsal állíthatjuk be, és lsattr-rel nézhetjük meg. Amire konkrétan kérdeztél, azt pedig a chattr -i <fájl/könyvtárnév> paranccsal érheted el. A -i az immutable, vagyis megváltoztathatatlan.

[quote:80ade0dcb5="zither"]
Ext2 és Ext3 fájlrendszerek esetén van néhány plussz kiterjesztés, ami lehetővé teszi a szokásos chmod jogokon kívül további jogok definiálását. Ezek a további jogok globálisak, vagyis a rendszergazdára (root) is vonatkoznak. Ezeket a jogokat a chattr paranccsal állíthatjuk be, és lsattr-rel nézhetjük meg. Amire konkrétan kérdeztél, azt pedig a chattr -i <fájl/könyvtárnév> paranccsal érheted el. A -i az immutable, vagyis megváltoztathatatlan.

Most nézem, hogy ezt már írták előttem, na mindegy...

hy!

van olyan ext3-on, hogy töredezettségmentesítés? mert korábban mindenki azt mondta, hogy olyat nem is kell csinálni, elvégzi az oprendszer, szépen elegánsan háttérben. de én szeretnék akkor amikor én akaork.. meg a legutóbbi induláskor jött a 30 naponta szokásos ellenőrzés és szolidan megjegyezte, hogy 4,6 százalékos a fragmentation. azzal lehet valamit kezdeni?

[quote:ededbbc599="batyu"][quote:ededbbc599="Adi"]Pl. elhasalni nagyobb terhelésnél, MySQL alatt? :roll:

Ami azt illeti, erről csak olvastam, itt fut ugyan mysql, de nem veszett nagy terheléssel, viszont gyakoribb probléma az ostoba user, uh. még terhelés mellett is ezt választanám...

Nekem sajnos volt belőle problémám. :x A gépen egy Woody és a hozzá tartozó 3.23.49-es MySQL fut, ami régi ugyan, de működik. A MySQL-nek külön partíció, XFS-sel. Eddig 2-3-szor okozott olyan gondot, hogy az XFS modul minden lemez I/O-t megfogott, a több partícióra se lehetett írni, ergo a gép pingethető maradt kivülről, viszont semmi szolgáltatás nem volt elérhető. Szervízprocival lehetett távolról resetelni, majd utána kezdtem el turkálni, hogy mitől is lehet a gond és így jutottam el az XFS-ig. Azóta ofkorsz Ext3-on fut a kérdéses partíció, de valószínűleg szinte mindent vissza fogok konvertálni arra, ami kicsit is terhelve van.

[quote:ab2acd2df6="johans"]- Fájlrendszer átméretezés: ext3 és reiser megy, de csak offline. XFS-t és JFS-t tudtommal nem lehet átméretezni.

Tudtommal mindkettot lehet, az XFSt azonban csak boviteni lehet, lecsokkenteni a meretet nem. JFSt nem ismerem, de azt is lehet szerintem nagyobbitani.

XFSt en is melegen ajanlom, jol birja a terhelest. Nekem reiserrel se volt rossz tapasztalatom, de tobb helyrol hallottam mar, hogy a nagy terhelest nem birja. (Sajat tapasztalat alapjan nem tudom megerositeni, nekem reiser is nagyon bevalt)

[quote:4bf3c1d436="onyx"][quote:4bf3c1d436="johans"]- Fájlrendszer átméretezés: ext3 és reiser megy, de csak offline. XFS-t és JFS-t tudtommal nem lehet átméretezni.

Tudtommal mindkettot lehet, az XFSt azonban csak boviteni lehet, lecsokkenteni a meretet nem. JFSt nem ismerem, de azt is lehet szerintem nagyobbitani.

Igazad van, utánanéztem. Az xfs-t lehet növelni, méghozzá online (pontosabban csak online lehet, offline nem), és a jfs-t is lehet növelni, offline.

[quote:1c22e1bd4a="Zahy"]
megj. 2: az igaz, hogy a SoftUpdates -et background fsck-val kell használni, és ez gyorsítja a rendszerindítást; majd X (konfigurálható idő után) elindul a rendes ellenőrzés és ez fogja a diszket, de jó lenne egyszer azt rendesen le is tesztelni, hogy mekkora az a "hatalmas" performanciavisszaesés, amit ez okoz.

Van tapasztalatom vele olyan diszktömbön, amely 100%-ra van járatva. Érezhetően (értsd: komolyan) belassul tőle.

De ez lenne a kisebb gond. A nagyobb az, hogy többször sikerült már megismételni azt a bravúrt, hogy nem tiszta leállás után a background fsck-val indított rendszer x. nap múlva meghalt. Minden külső jel nélkül, egyszerűen megállt. Az x teljesen változó és még csak azt sem mondanám, hogy terhelésfüggő, mert a desktop gépemen is ment vagy 4-5 napig és a durva terhelésű fájlszerveren is volt, hogy bírta 10-15 napig.

Érdekes módon, ha ezután kézzel fsck-zok, megjavul a téma, hónapokig megy a gép mindenféle hiba nélkül.

Nálam minden ilyen szempontból kritikus rendszeren ott van a
background_fsck="NO" az rc.conf-ban... Ez van, erre lehet készülni. Ha FreeBSD-t használsz, olyan rendszert építs, amelynél nem gond, ha percekig, vagy órákig fsck-zik a gép. :)

[quote:80bef04806="Zahy"]
megj. 3: bennem egyre inkább az a kép alakul itt ki, hogy a ReiserFS hatalmas sikere technikailag kevésbé megalapozott, inkább "sztárolásnak" tűnik - legalábbis mintha az ext3 többet tudna.

Ez azért viccnek is rossz. Az ext3 egy ext2 hack, csak hozzáadták a naplózást. A Reiser meg egy újabb fejlesztés, aminek persze eleinte sok hibája volt. A Reiser teljesítménye jobb, a helykihasználása optimálisabb, a sok kis file kezelése is gyorsabb és hatékonyabb, a hibás lecsatolás utáni elenőrzés és helyreáálítás szinten gyors és hatékony. Hátránya, hogy mindez nagyobb CPU használattal jár.

Azért ha tényleg érdekel valami akkor minimálisan utána lehet ám olvani a neten és nem a mendemondak alapján írni összehasonlítást.

Én két kisterhelésű szerveren és itthon használom a Resiserfs-t, volt sok váratlan leallás áramszünet és egyebek miatt, de eddig nem veszett el semmi és kézi beavatkozásra sem volt szükség.

Sok rémtörténetet olvasni a neten, de ez inkább hozzánemértés eredménye és más filerendszerrel is megesik.

ACL meg használható vele természetesen.

Pedig Zahynak van igaza. Nézzük a tényeket:

- Olvasás: az olvasási teljesítményt alapvetően az IO sávszélességed és a cache méreted / cache stratégiád határozza meg. Emlékeim szerint a cache a VFS része, tehát egy absztrakciós réteggel feljebb van, mint a fájlrendszerek, ezért ez ugyan az mindenhol. Az ext3 és az ext2 közötti különbség csak a directoryban található i-node tárolási módszerben lehet. Ebben jobb a reiser a kiegyensúlyozott B fával, viszont a különbség életszerű környezetben (nincs néhány tízezerezer fájlod egy directoryban, mert azt vagy szétszelektálod több subdirre, vagy adatbázisba rakod) nem mérhető.

- Írás: az írási teljesítményt alapvetően (ilyen sorrendben) az IO sávszélesség, a cache, a journal kezelési módja, és az egyéb, íráskor végzett műveletek határozzák meg. Ebből az utolsó két pontban lehet különbség. Na most, a reiser-ben használt algoritmus adatinkonzisztenciát okozhat. Nem a fájlrendszered sérül, hanem olyan állapot állhat elő, amiben a működés során nem volt a gép. Pl. írsz A-ba, írsz B-be, majd reset, mindkét fájlnak megváltozott a hossza, de A-ban a régi tartalom van benn, B-ben meg az új. Ez az unordered journálnál simán előfordul, és ettől az applikációs szint fejre bír állni. Ext3-nál is el tudod ezt érni, ha a writeback módba állítod a journalt, viszont ekkor a teljesítménye is hasonló (lényegesen nem eltérő) a reiserhez képest. A directoryk kezelésekor (írás esetén) pedig a reiser kifejezetten lassabb, mint az ext3, mert egyrészt ki kell egyensúlyozni a B fát, másrészt a varázslatos "tail" opció is bejön, ami miatt blokkon belül több kis fájl is lehet... Ez valóban helymegtakarítást jelenth, de hogy a sebességnek nem tesz jót, az biztos.

én ext3-t és reisert is használok
nekem eddig (vinyókábel hibája miatt) kétszer volt gondom filerendszerrel, mindkétszer a reiser sérült úgy, hogy órákig szenvedtem kézzel mire a cuccokat vissza tudtam pecázni a lost+found-ból, az ext3-at simán megcsinálta az automatikus fsck

csak azért egyet ne felejts el, hogy a sun minden komolyabb rendszerhez a veritas cuccat rakja alá és nem ufs-t használ

[quote:aee2ab700b="maglyarakas"]csak azért egyet ne felejts el, hogy a sun minden komolyabb rendszerhez a veritas cuccat rakja alá és nem ufs-t használ

Elég sok komoly sun-os rendszert láttam (10K-kból és 15K-kból épített clusterekhez is volt szerencsém), a SUN maximum a volume managernek ajánlja a veritast, 3-as sun clustertől kezdve már annak sem. De ez kezd kicsit off-topic lenni.

Épp erről van szó, a reiserfs-nel az ordered mód a default, ezt persze sokszor elállítják, aztán gond van. Mérést ugyan nem végeztem, de érzésem szerint azért a sok kis fájlon végzett műveletek akkor is gyorsabbak, ha nem egy könyvtárban vannak, de ez csak magánválemény.

Zahy bocs, ha esetleg sértőt írtam és igen a HUP nagyon is a net része, de a forumok ilyen esetben szerintem nem az elsődleges források, ezt szerintem nem kell magyarazni.

Nem mondom, hogy a Sun barom, de ezzel az erővel lehet minden fs használatra céges példát hozni. A cégeket meg főleg a profit érdekli és a jogdíjak, nem a technológiák.

Nem gondolom, hogy jobb, pont azért mondtam, hogy fiatalabb, hogy elofordulhatnak gondok. Mindig vannak akik fikázzák az új dolgokat, csak azért soha ne feledjük, hogy nem ezek az emberek viszik előbbre a dolgokat.

A vélemény meg valóban szabad, ezért mondom, hogy ne csak a fórumban nézd. Pl. a fs tool-ok man-jából egy csomó érdekességet ki lehet hámozni pl. a badblock nyilvántartásról és a naplók elhelyezéséről, stb.

ranger

Azt a wikipedia linket legyszi megegyszer kozzetenned, esteleg szoveg formaban is, ha meg mindig bug van
Koszi
http://hup.hu/modules.php?name=Forums&file=viewtopic&p=69248#69248

Amennyire én tudom, az Extended Atributumokat az Ext2, Ext3, és Reiser Fájlrendszerek tudják. Egyetlen feltétel, hogy a kernelbe bele legyen forgatva, vagy modulként rendelkezésre álljon a kezeléséhez szükséges kódrész. Ez a hivatalos kernel rész, vagyis szinte biztos, hogy rendlekezésre áll.
Azt hiszem a lemez kvótát a kernelben egy alrendszer végzi, vagyis bármilyen olyan fájlrendszeren megvalósítható, amelyen a tulajdonosok megfelelően nyilván vannak tartva.

Igazából ebben a témakörben, amiről kérdezel nem vagyok otthon, ezért nem nagyon tudok a kérdéseidre válaszolni. Minden esetre az általad felsoroltakon kívül én nem ismerek több naplózós fájlrendszert (bár én csak hármoról tudtam, az xfs nekem is újdonság)

http://en.wikipedia.org/wiki/Comparison_of_file_systems

:wink:

[quote:3383c96da1="zither"]... Minden esetre az általad felsoroltakon kívül én nem ismerek több naplózós fájlrendszert (bár én csak hármoról tudtam, az xfs nekem is újdonság)

Pedig nem új dolog, már jóideje (vagy két éve) használom nagy megelégedéssel én is. Már a 2.4.x-es kernelekben is volt hivatalos támogatás hozzá, meg korábban peccs. Amióta egyszer elhasaltam ext3-al, mindenhova ezt rakom. Bírja a viszonylag gyakori áramszüneteket, ostoba userek poweroffjait... és tudja amit tudnia kell egy korszerű filerendszernek.

[quote:3383c96da1="Zahy"]... Az ext3-t ismerem (?), ezt szereti/preferálja ha jól tudom a RedHat (meg utódok, Fedora, CentOS) - annyira, hogy a pár napja telepített CentOS felismerni ugyan felismerte a meglevő XFS-t, JFS-t és ReiserFS-t, de ő ilyet nem tudott csinálni.

Dehogynem tud, csak ez nem csak a kernelen múlik, kell hozzá az xfstools is, ahogy az ext2/3-hoz meg a többihez is kell a megfelelő tool, csak azokat az alaptelepítés felrakja. A kernel support csak ahoz elég, hogy csatolni/olvasni tudja.
Üdv!

Batyu'

[quote:56805fa65f="batyu"][quote:56805fa65f="zither"]... Minden esetre az általad felsoroltakon kívül én nem ismerek több naplózós fájlrendszert (bár én csak hármoról tudtam, az xfs nekem is újdonság)

Pedig nem új dolog, már jóideje (vagy két éve) használom nagy megelégedéssel én is. Már a 2.4.x-es kernelekben is volt hivatalos támogatás hozzá, meg korábban peccs. Amióta egyszer elhasaltam ext3-al, mindenhova ezt rakom. Bírja a viszonylag gyakori áramszüneteket, ostoba userek poweroffjait... és tudja amit tudnia kell egy korszerű filerendszernek.

Pl. elhasalni nagyobb terhelésnél, MySQL alatt? :roll:

[quote:9c6a9de1a6="Zahy"]... és úgy tudom, hogy nem ugyanaz a JFS, mint ami az AIX -ben van (és amit egyesek JFS2-nek neveznek), hanem állítólag az OS/2-ben meglevő, egyszerűbbnek, kisebb tudásúnak tekintett. ...

Szia!

<OFF>
Ne haragudj, hogy megnyírbáltam a hozzászólásodat, de nem akartam olyan hosszút idézni, és szerintem nem veszített a jelentéséből azzal kapcsolatban, amit mondani szeretnék.

<ON>

Mielőtt valaki félreérti, és elkezdi keverni a HPFS-t a JFS-sel. Az OS/2 eredeti file-rendszere a HPFS. A JFS-t utólag port-olta az IBM OS/2-re.
Ha minden érdeklődő tud angolul, akkor: http://en.wikipedia.org/wiki/JFS .
Ha nem, akkor szóljatok, megpróbálom összefoglalni magyarul.

Üdv.: Tomyellow

[quote:3cd72370f3="Zahy"]
Amik érdekelnének:
a) milyenek vannak még?
b) a következőket melyek tudják (lehetőleg plusz peccs nélkül, esetleg valamely nagyobb disztribben alapból pecselve, bár ez ugyebár nehezíti a kernel frissítést):
- kvóta
- ACL
- EA (azaz Extended Attribute) - ha jól tudom, pl. a Selinux működéséhez (pl. fent említett CentOS-ben) kellenek valamely plusz információ tárolásához
- fájlrendszer átméretezés föl/le, ad abszurdum online
- online mentési lehetőség (mondjuk fájlrendszer snapshot)

Köszönöm.

A kernelbeli reiser3 selinuxhoz egyenlőre felejtős. Az EA/ACL implementációja nem kielégítő.

Egyszer csináltam ostoba-user-poweroff tesztet egy telepítésre váró rendszeren. Az ext3 kiállta a próbát. A reiser3 nem. Ugyanakkor a reiser3 sokkel gyorsabb volt. Meg megtanultam azt is, hogy dd-zés akkor korrekt igazán reiser3-on, ha "notail"-lel van mountolva. (XFS-t nem teszteltem)

Üdv,
Dw.