[Top] [All Lists]

Re: Comparing XFS with ext3 and ReiserFS

To: Federico Sevilla III <jijo@xxxxxxxxxxxxxxx>
Subject: Re: Comparing XFS with ext3 and ReiserFS
From: Andi Kleen <ak@xxxxxxx>
Date: Sun, 6 May 2001 12:48:08 +0200
Cc: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.21.0105061818500.10780-100000@xxxxxxxxxxxxxxxxxxx>; from jijo@xxxxxxxxxxxxxxx on Sun, May 06, 2001 at 06:24:12PM +0800
References: <Pine.LNX.4.21.0105061818500.10780-100000@xxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Sun, May 06, 2001 at 06:24:12PM +0800, Federico Sevilla III wrote:
> Does anyone have information on performance? Space utilization?
> Reliability when recovering from unclean shutdowns?

I hear there is a secret source called "xfs website" which
has information on all that and more.

> In the area of reliability when recovering from unclean shutdowns I'm
> particularly interested at how XFS deals with its cache/buffer. For
> example in mail queues, with ext2 directories can be flagged using chattr
> as +S so that all work done with these directories are synchronous. A
> little slower, but this is much more stable especially for these queues.
> With ReiserFS AFAIK mail queues currently run on a risk because perfectly
> timed power downs could cause mail to "disappear". How would situations
> like this be handled by XFS?

reiserfs doesn't have this problem. Although it doesn't have synchronous
metadata flushing it has fully sequential metadata flushing. This means
if the mail application did an fsync() on the file data (which it has to) 
then after the fsync returns the directory entry of the file should be
safely on disk because it was created in an earlier transaction, and 
transactions are always flushed in order.
XFS has similar semantics AFAIK.

[modulo IDE/SCSI write cache issues of course; to be really safe you would need
to turn it off but the performance goes through the toilet -- this caveat 
is shared by any file system or application the relies on ordered writes]


<Prev in Thread] Current Thread [Next in Thread>