Journaling File Systems and RAID (was RE: [ale] ext3)

[Armsby John-G16665]

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?

John



-----Original Message-----
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 
access pattern.


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.