Donald Tripp wrote:
> This argument sounds vary familiar to NFS vs GFS vs Lustre vs GPFS... 
> All file systems have their pros and cons, and no file system is fool 
> proof. XFS is a good file system, so is Reiser, and ext3, and HFS 
> (Apple), but they all have their own faults. 
> 
> Just my 2 cents...
> 

Yes and no,
Faster and slower is one thing, data corruption is another.

OK, so I decided pull out the "way back" machine and go through old mail.

 From November 2006, from Peter Kelemen at CERN
---------
Starting with RHEL4, the 4KSTACKS option is enabled when the
kernel is compiled.  This limits each process' kernel stack to
4K with separate stack for interrupts.  XFS can have deep call
chains (it's a complex filesystem doing complex stuff) and the
codebase included in SL4 has not been updated to take this reduced
stackspace into consideration (it's effectively the XFS codebase
from the 2.6.9 times).  As a result, it is possible to load the
machine so that XFS overflows its stack and then the game is
over.  It can be easily triggered by stacking several software
layers (SCSI+LVM/MD+XFS+NFS) on top of each other but it has
been demonstrated that the stack overflow can be triggered with
sufficient load on plain SCSI+XFS systems as well.
-------------

That is the most clear description of the problem I think

Now, this is from May, in a discussion about CentOS's XFS kernel modules in 
CentOS 5
This is Axel Thimm responding
-------------------
 > Wern't they having problems with it on 32 bit?  Just like before?  Or
 > > was I reading those e-mails wrong.

That is supposedly solved, and the two lead developers at SGI on XFS
on Linux now have @redhat.com addresses and thus RH got some XFS love,
too (previously there was a strong Suse link). Still RH pushes for
its favourite filesystems, e.g. ext3/4 and gfs2.
---------------------

So there might be light at the end of the tunnel for 32 bit.
But ... that also might mean that now the lead developers that were fixing XFS 
had different projects at RedHat so the XFS development has lost it's 
developers.  I personally don't know.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________