-----Original Message-----
From: fedora-test-list-bounces(a)redhat.com
[mailto:fedora-test-list-bounces@redhat.com]On Behalf Of Tom Mitchell
Sent: Tuesday, April 27, 2004 7:24 PM
To: For testers of Fedora Core development releases
Subject: Re: OT - Journaling File Systems?
On Tue, Apr 27, 2004 at 12:03:35PM -0500, Edwards, Scott (MED, Kelly
IT
Resouces) wrote:
> Does anyone know of any comparisons of ext3, jfs, xfs and reiser
for
> reliability?
....
> Next I tried XFS. I was excited at first because a normal bootup was
> only 18 seconds. The first reboot after a 'plug pull' was only 27
> seconds (and I think that included the 5 second wait). I was very
> excited to see this improvement over ext3. However, it was short lived.
> After the second 'plug pull' it took 1 minute and 16 seconds to boot.
> But it claimed corrupted metadata and that the superblock was trashed
> and could not even mount the partiton.
Can you tell us (me) more about the hardware and test setup.....
Disks, Single or multiple disk in system, Raid?, controllers,
partition, SCSI, EIDE, FC, SIDE, cable width, speed, DMA
tagged-queuing depth, hdparm -I, Buffer modes in the disk and
controller, read buffers, write buffers, mkfs options.
It is actually a very simple/basic setup. It is a Single Board
Computer, 3.0 GHz Pentium 4. It has 2 IDE connectors and 2 SATA
connectors on the board. There is a CD-ROM drive pluged into IDE 1
and a single SATA drive plugged into the first SATA port. No RAID
or anything like that.
The machine is reconfigured at the moment with a IDE drive so I
can't give you the hdparm -I. I can say that because it thinks it
is a SCSI drive, hdparm won't allow me to turn off the write
caching.
I am curious why FC2 mounts it as a SCSI drive, whereas Knoppix
makes it an IDE drive (hdg). I am guessing that is a change in
the 2.6 kernel?
XFS requires effective atomic and strictly ordered writes for meta
data consistency. In multiple processor environments strong mutual
exclusion locks are a requirement. I suspect that this is true for
all file systems. Is this a multiprocessor box?
It only has one CPU. I'm confused about the whole Hyper-Threading
thing, Linux seems to treat it as multiple processors.
Any 'plug pull' safe disk needs some sort of hardware logic to
sense
power failure, then self-power long enough to finish the committed
writes and not start others. Does the power supply signal the system
with a power-fail line? Does the mother board signal the OS with a
power-fail interrupt? The more RAM on the disk dedicated for write
buffering the more interesting the write buffer issues on the disk
are.
I don't believe that there is any special anything for power fail.
The HD is a Hitachi 164.7GB Deskpro, which I'm pretty sure is just
an off the shelf drive. I'm trying to get the specs right now.
What is the ratio of data to meta data in your test. XFS can
allocate
lots of data blocks for data and be lazy with the meta data. This
implies that the data read from a file after a failure will be correct
or simply absent in part depending on how it was written. This ratio
with the meta data sync time etc. can define the number of faces on
the die in terms of how often meta-data will be be corrupt.
I'm not really sure what the ratio is. The last few tests I have run
(which have ended up in corrupting the filesystem to the point it
wouldn't even boot) was simply start a 'cp -pirv /etc /tmp' and switch
off the power.
Are you pulling the power plug on the disk (DC,5V,12V), disk box (AC)
or
the
wall plug (AC) for the entire system (disk,MB,processor,DRAM...)?
It would be the wall plug. The scenario I am testing for is someone
tripping over the power cord and accidentally pulling the plug out
of the wall while it is in operation.
Thanks
-Scott