l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
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



> 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
> journaling.
> 
> Okay, guys, correct me where I'm wrong!

In a theoretical world where no sector dies, no corrupted data gets
written, no valid data ends up on the wrong block, and no OS, application,
or device driver errors your correct.

You should only lose data that was never writen or happens to be in the
journal as having been partially completed are lost.

But in the real world corruptions do happen, and just because a
transaction is completed and removed from the journal does not mean that
the large elaborate datastructure that contains the disks metadata is
not corrupted.

Theres no way to verify similar without actually reading it and double
checking whatever checksums, consistancy checks, and redundant info
checks.

So basically you can be MUCH more sure of a disk that has been fscked
and reported no errors then you can be a journaled filesystem where the
os double checks the transaction journal and deems the filesystem "clean".

--
Bill


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
O'Reilly and Associates
For numerous book donations.