Journaling File Systems and RAID (was RE: [ale] ext3)
John.Armsby at motorola.com
Wed Sep 19 16:53:16 EDT 2001
I thought the journaling file system gave you a more stable file system in the event of a "glitch".Â We will probably will move from an HP web server to RED HAT.Â I was going to suggest Reiser as the file system.Â The disk array will be around 40 gigs.Â Are you guys telling me, what is driving journaling file systems is the FSCK annoyance?
From: Stephan Uphoff [mailto:ups at tree.com]
To: ale at ale.org
Sent: Wednesday, September 19, 2001 4:35 PM
To: Vernard Martin
Cc: ale at ale.org; ups at tree.com
Subject: Re: Journaling File Systems and RAID (was RE: [ale] ext3)
> Vernard Martin wrote:
> And regardless of implementation, the amount of data that is written
> with a journaling filesystem versus a non-journaling filesystem (keeping
> everything else the same) is going to be larger so its going to
> technically take longer.
This really depends on the implementation and the file system
In some implementations many short log entries share a single log block.
The log entries describe changes in multiple meta data blocks.
Since the log contains a description on how to recover meta data
the (non log) meta data blocks do not have to be flushed for file
(or file system)Â synchronization or to satisfy fsck requirements
- it is enough to flush the log block(s).
( To be able to recover with fsck some writes to disk need to be synchronous
Â in a regular file system )
Because of this (non log) meta data does not need to be flushed as frequently
as with a regular file system.
This ``write caching'' can actually decreases the amount of data traffic
to the drive.
As with all caching the effectiveness depends on the
access pattern and the size of the cache.
Â Â Â Â Â Â Â Stephan
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.
More information about the Ale