l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:00

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Journaling File Systems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Journaling File Systems

On Tue, Feb 13, 2001 at 01:34:45AM -0800, Bill Broadley wrote:
> In general journaling filesystems make larger assumptions about the
> state of the filesystem, and because of it can boot much faster.
> Thats the good side, the bad side is that when booted after rolling back
> the journal there is much less of a guarentee of integrity.
> With the ext2 filesystem after a full FSCK you can be pretty sure that
> close to 100% of the metadata is correct, or that you will be notified
> and most often have fsck repair the damage.  This protects against
> something like a strange power situation causing a block being written
> to random part of the disk, and running for say a month then realizing
> some directory is completely corrupted.
> Other up and coming filesystems:
>       Ext3
>       Jfs (Ibm)
>       xfs (sgi)
>       gfs (shared disk cluster filesystem for linux)
>       intermezzo (new distributed fs focussed on high availability)
>       coda (advanced networked filesystem, seems to be dying)
> Of course the big awaited functionality that many are waiting on
> is the LVM = Logical Volume Manager which should allow
> growing/shrinking partitions as well as adding additional
> devices into a pool of disk and similar.
> My suggestion is to use EXT2 when reliability and recoverability
> are most important.  For data thats either replicated, backed up, 
> or replacable use whatever floats your boat.


IANAE, but this is completely the opposite of what I've understood,
given a brief overview of exactly how journaling fs's work.  They are
substantially /more/ reliable as well as faster on boot; because they
journal (hence the name) every option immediately prior to attempting
it, and then mark it as completed once it's through.  This way, they
have a record of all the things that completed successfully, and a
short, easily accessible list of any operations which did /not/
complete successfully, and so rather than checking the /entire/ disk,
they can simply check the operations which didn't complete, and revert
them to the value they held before the crash.  The tradeoff is not
reliability at all - you're getting reliability as a /benefit/ of
using a journaling fs, along with the speedier boot.  The tradeoff
(there always is one), is more disk space being used by the fs for the

Okay, guys, correct me where I'm wrong!


LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.