Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

interesting note on fsck and journalled filesystems



Just ran across this on the Mandrake mailing list - it looks like journaling 
filesystems aren't quite bullet proof yet...

List:       mandrake-cooker
Subject:    Re: [Cooker] [Bug 4862] [initscripts] running e2fsck on ext3 often
From:       Thierry Vignaud <tvignaud () mandrakesoft ! com>
Date:       2003-09-17 11:49:04

"[danny]" <bugzilla at qa.linux-mandrake.com> writes:

> It sounds as you actually want fsck to check journalled drives,

yes, i do want checking journalized fses by default if the user does
not choose anything.

> while, in my experience, the journal update at mount is much safer
> than fsck

in my experience, not checking journalized fses can results in slowly
accumulating small corruption in metadata until the day you got real
problems because of this.

journalised fses provides quite more stable fs regarding metadata
lost and big corruptions but that does not means they protect you
against all fs corruptions.

i often see small mismatch in free/used iodes/blocks after journal
replaying.

these small glitches can cause bigger damage later if not fixed.

> (which doesn't use the journal to restore, but just fixes incorrect
> stuff, which usually means: deletes incorrect stuff).

current fsck for ext3 does replay journal *before* checking & fixing
it.

i cannot speak for other journalised fses though.
i've only heavily test ext3 but neither jfs nor xfs nor reiserfs.






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org