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



The quest for a bullet proof filesystem will continue.  Linux is a
really great test and development platform for this.  It seems to
support more filesystems more easily than any other OS I can think of.

Some journalled filesystems depend entirely on their journals for
recovery and don't really have any way to be checked and fixed.  In my
sysadmin experience this is probably not a good thing, although having a
relatively quick binary decision on whether you need to recover from
backups is helpful in the same way a kernel panic keeps you from getting
into worse trouble.  I kind of like ext3's dual nature in that respect. 
You can't have too many ways to recover a filesystem gone bad.

On Sat, 2004-01-10 at 00:27, Glenn Burkhardt wrote:
> 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.
> 
> 
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss





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