Naplózó UFS gjournal-lal

FreeBSD

Annak ellenére, hogy egyes BSD felhasználók állandóan hangoztatják, hogy semmi szükség nincs a BSD-kben naplózó filerendszerre, több próbálkozás is van fejlesztők részéről BSD-s journaling FS és / vagy keretrendszer implementálására. Pawel Dawidek egyik mostani levelében a gjournal névre hallgató munkájáról írt. Ez nem más, mint egy naplózó alrendszer a FreeBSD 6.x és 7.x-hez.

A gjournal gyakorlatilag FS független, így naplózási szolgáltatást biztosíthat elvileg bármely filerendszer számára. Ehhez a filerendszerekben minimális változtatást kell elvégezni. Jelenleg ezek a változtatások az UFS filerendszerhez készültek el, illetve vannak készülőben.

A gjournal használata kis file-ok esetén egész gyors, viszont nagy file-ok esetén lassabb. A fejlesztő azt ígéri, hogy a gjournal használata esetén nincs szükség fsck(8)-ra egy váratlan rendszerleállás / leállítás után.

A fejlesztő levele itt.

( nc | 2006. 06. 20., k – 13:59 )

Egy jó rendszernél ez tényleg igen ritka alkalom, így az ember azt érzi egy idő után: most mi a különbség hogy mondjuk ext3 van fenn ext2 helyett?

Érdekesnek tűnik.
Nem akarok flame-wart, ezért is inkább itt kérdezem és nem külön topicban.
Melyik BSD-t érdemes használni?
Jelenleg saját tulajdonú szerverként üzemeltetek egy Debian-t és egy Solaris-t. (Leginkább web, mail, DNS hosting) A BSD-k ről már elég sokat hallottam, olyan emberektől is akiknek adok a véleményére. Szóval gondoltam megismerkedek eggyel, ami kb. a fenti két rendszer mellé beillene. Aztán majd később maradok annál, amelyikkel gazdaságosabb foglalkozni. Én FreeBSD-re gondoltam, bár nem nagyon ismerem a külömbségeket. Előny az is ha ingyenes, vagy "elég olcsó", viszont kereskedelmi célra is lehessen használni.
(No, tessék kimoderálni, ha ez nem való ide.)

Rühelltem az ext2 -öt, mert iszonyúan nem bírta a szabálytalan leállást (powergomb -ba belerúgást, áramszűnetet, stb.), és nem igazán éreztem gyorsabbnak, mint a kásőbb megjelenő naplózó fájlrendszereket.

Pontosan ezért érdekelne, egy ésszerű, tartalmas magyarázat, mert biztos valami olyan áll mögötte, amit én még nem tudok, de szívesen tanulok, ha van mit. :)

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Pontosan ezért érdekelne, egy ésszerű, tartalmas magyarázat, mert biztos valami olyan áll mögötte, amit én még nem tudok, de szívesen tanulok, ha van mit. :)

Akkor adok egy elitista-BSDs választ. Diszkléjmer: ez nem feltétlen egyezik az én véleményemmel, de illik hogy legyen egy ilyen a szálban :)

Szóval... A BSD-k Más OSekhez képest lassan fejlődnek mert a BSDsek nem a gyors hekkek hívei, hanem az időtálló valódi megoldásokénak..

Jelen esetre vonatkoztatva: olvasd el háromszor lassan a beírásban szereplő A gjournal gyakorlatilag FS független mondatrészt, és közben mondd el a következő mantra egy-egy sorát respectively:

- a linux fejlesztők implementáltak egy zsurnálfst ext3 néven
- a linux fejlesztők implementáltak egy zsurnálfst reiserfs néven
- a linux fejlesztők implementáltak egy zsurnálfst xfs néven...

> A gjournal gyakorlatilag FS független

Van is annyira gyors és hatékony, mint egy natív implementáció?
És ne feledjük, ez még csak egy implementáció, ha jól emlékszem, korábban is voltak ilyen kezdeményezések, melyekről nem sokat hallhattunk utána. És azok talán nem is rendelkeztek az általad fentebb említett tulajdonsággal.

Mindenesetre, köszönöm a válaszod, valóban korrekt volt. :)

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Van is annyira gyors és hatékony, mint egy natív implementáció?
És ne feledjük, ez még csak egy implementáció, ha jól emlékszem, korábban is voltak ilyen kezdeményezések, melyekről nem sokat hallhattunk utána. És azok talán nem is rendelkeztek az általad fentebb említett tulajdonsággal.

Hat majd elvalik. Mindenesetre pjd mar jo regen koszorulte ezt a dolgot, -- szoval ez nem az a hetvegi proof-of-concept tipusu dolog --, s azt gyanitom, hamar meg fogja talalni ez a kod az utjat a CURRENT agba.