xfs
[Top] [All Lists]

Re: xfs_force_shutdown from line 1071 of xfs_trans.c

To: linux-xfs@xxxxxxxxxxx
Subject: Re: xfs_force_shutdown from line 1071 of xfs_trans.c
From: James Pearson <james-p@xxxxxxxxxxxxxxxxxx>
Date: Mon, 19 Jan 2004 10:44:58 +0000
Organization: Moving Picture Company
References: <A0366F44-46DF-11D8-82FD-003065F970BA@astro.wisc.edu>
Sender: linux-xfs-bounce@xxxxxxxxxxx
I've recently had a similar problem on a dual Xeon (NFS) server running
a 2.4.21 kernel with XFS 1.3:

Jan 18 13:14:57 sierra kernel: xfs_force_shutdown(sd(8,17),0x8) called
from line 1071 of file xfs_trans.c.  Return address = 0xc01cdc26
Jan 18 13:14:57 sierra kernel: Filesystem "sd(8,17)": Corruption of
in-memory data detected.  Shutting down filesystem: sd(8,17)
Jan 18 13:14:57 sierra kernel: Please umount the filesystem, and rectify
the problem(s)

The file system is on an external hardware RAID box, attached via SCSI
to an onboard aic7902 controller - using v1.3.10 of the aic79xx driver.

Details of the file system:

meta-data=/disk1                 isize=256    agcount=206,
agsize=1048576 blks
data     =                       bsize=4096   blocks=215060139,
imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=26252
realtime =none                   extsz=65536  blocks=0, rtextents=0


The system would have been serving files over NFS at the time.

Running xfs_repair on the file system afterwards reported no problems.

I've seen this problem a few times on other systems...

Any ideas what could be the problem?

Thanks

James Pearson

Stephan L Jansen wrote:
> 
> Hi,
> 
> I have a ~ 80GB parition (5 disk hardware RAID 0) on a two processor
> Dell 2650.  I
> have seen two xfs_force_shutdowns on it in the last few days.  The
> filesystem is
> accessed largely via NFS by between 50 or 100 processes on remote
> machines.  I'm
> currently running 2.4.20-28_36.rh8.0.atsmp which is XFS 1.3.0.  There
> are no other
> logs in either syslog or dmesg.  Here's the error message:
> 
> Jan 14 10:27:16 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x8) called
> from line 1071 of file xfs_trans.c.  Return address = 0xf88d26eb
> Jan 14 10:27:16 glimpse4 kernel: Filesystem "sd(8,5)": Corruption of
> in-memory data detected.  Shutting down filesystem: sd(8,5)
> Jan 14 10:27:16 glimpse4 kernel: Please umount the filesystem, and
> rectify the problem(s)
> Jan 14 10:27:16 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x2) called
> from line 747 of file xfs_log.c.  Return address = 0xf88d26eb
> 
> For various reasons I was running an older kernel 1.2.0 when this first
> showed up.  The message from
> 1.2.0 appears to be an old bug (see
> http://oss.sgi.com/bugzilla/show_bug.cgi?id=186).  Here's the message
> from that kernel:
> 
> Jan 11 13:22:32 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x8) called
> from line 1042 of file xfs_trans.c.  Return address = 0xc01d3738
> Jan 11 13:22:32 glimpse4 kernel: xfs_force_shutdown(sd(8,5),0x2) called
> from line 721 of file xfs_log.c.  Return address = 0xc01c53a1
> 
> Here's the output from xfs_info
> 
> xfs_info /usr/data/glimpse4
> 
> meta-data=/usr/data/glimpse4     isize=256    agcount=20,
> agsize=1048576 blks
>           =                       sectsz=512
> data     =                       bsize=4096   blocks=20384469,
> imaxpct=25
>           =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=2488, version=1
>           =                       sectsz=512   sunit=0 blks
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> 
> Should I backup, mkfs and restore?
> 
> ------- Stephan


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