Hi guys,

> 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.
> -------------

I second Troy's description there, I used SL4 32bit and ran into the above
problem after stacking scsi+md++drbd+lvm+xfs, guess what? it just stopped
working and I was forced to move to ext3 even though I didn't want to.

Of course, SL4 64it kernel doesn't have this problem.

> 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.

XFS is great and my choice of filesystem, but you can make ext3 perform the
same as XFS by turning off redundancy features inherently turned on by default
on ext3.

The new kid on the block? Sun's ZFS which blows all these other filesystems
out of the water when it comes to feature-sets. For now, we have to stay a
step behind in the Linux world until such a filesystem becomes mainstream.

Regards,

Michael.

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