Hi

  We were experimentally using XFS file system on our anonymous ftp
server with Scientific Linux 4.2  (i386) in this spring. Kernel was
build from the original kernel source 2.6.14.3 (latest at that time)
from kernel.org with XFS flags enabled. Also centosplus kernel which
supports XFS/JFS/Reiser FS was experimentally used.

  At the beginning, we noticed that the XFS file system is faster
then ext3. But after a few days, we have experienced frequent
PANIC with "kernel stack overflow."

  And then,  the XFS file systems started to be corrupted.

Mar 29 16:10:43 fff kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO 
at line 1714 of file fs/xfs/xfs_alloc.c.  Caller 0xf8a229f7
Mar 29 16:37:00 fff kernel: XFS internal error XFS_WANT_CORRUPTED_GOTO 
at line 1714 of file fs/xfs/xfs_alloc.c.  Caller 0xf8a229f7
Mar 29 23:25:01 fff kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN 
at line 310 of file fs/xfs/xfs_alloc.c.  Caller 0xf8a20d1e
Mar 30 00:06:43 fff kernel: XFS internal error 
XFS_WANT_CORet_pages_tag+0x28/0x64
Mar 30 00:06:43 fff kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN 
at line 310 of file fs/xfs/xfs_alloc.c.  Caller 0xf8a20d1e
Mar 30 00:12:44 fff kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN 
at line 310 of file fs/xfs/xfs_alloc.c.  Caller 0xf8a2
Mar 30 00:12:44 fff kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN 
at line 310 of file fs/xfs/xfs_alloc.c.  Caller 0xf8a20d1e
Mar 30 09:24:46 fff kernel: Filesystem "sdb1": XFS internal error 
xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c.  Caller 
0xf8a3d1dc
Mar 30 09:24:47 fff kernel: Filesystem "sdb1": XFS internal error 
xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c.  Caller 
0xf8a3d1dc
Mar 30 09:24:47 fff kernel: Filesystem "sdb1": XFS internal error 
xfs_da_do_buf(1) at line 2176 of file fs/xfs/xfs_da_btree.c.  Caller 
0xf8a3d1dc
  :

For example, file size of x051_BPA.mf shows 4.3TB. This should not be.
.
|$ ls -l
|total 68
|-rw-rw-r--  1 archive archive           347 Jul 14  2005 CAN_trigorgon.mf
|-rw-rw-r--  1 archive archive           198 Aug 16  2005 x050_diastoli.mf
|-rw-rw-r--  1 archive archive 4398046511287 Aug 17  2005 x051_BPA.mf
 :

  Therefore, we decided to switch back all the file systems from XFS to
ext3 with standard Scientific Linux distribution kernel on our ftp
server (i386). After that, the ftp server becomes stable again with
ext3 file systems on SL distribution kernel.

  On the other hand, we are still using XFS file systems on several
X86_64 nodes with Scientific Linux (X86_64) for more than two years
and these seems to be very stable.  My personal impression is that
XFS on "i386"  architecture is not stable.

Takashi Ichihara  (RIKEN)

KELEMEN Peter wrote:
> * Urs Beyerle ([log in to unmask]) [20061115 11:13]:
>
>   
>> As written in
>> ftp://ftp.scientificlinux.org/linux/scientific/44/i386/contrib/RPMS/xfs/README,
>> XFS is not recommended on SL4 32bit kernels.
>>     
>
> Correct.
>
>   
>> What kind of problems where observed?
>>     
>
> 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.
>
>   
>> Is somebody working on a solution, which does not require to
>> recompile the standard SL4 kernel?
>>     
>
> The proper solution would be to backport stack-usage reducing XFS
> patches from newer vanilla kernels to the SL4 kernel.  AFAICT
> nobody is working on it actively as we speak.  There are some
> garage projects here and there (hint-hint ;) but no ETA and
> certainly no commitment.  Your best bet is to move to 64-bit
> platform (practically any CPU you can buy nowadays would qualify).
>
> Peter
>
>