On Fri, 2008-06-13 at 13:08 +1000, Dave Chinner wrote:
> On Fri, Jun 13, 2008 at 12:27:09AM +0200, Miquel van Smoorenburg wrote:
> > On Thu, 2008-06-12 at 16:33 +0200, Oliver Pinter wrote:
> > > add CC's
> > >
> > > On 6/12/08, lists@xxxxxxxxx <lists@xxxxxxxxx> wrote:
> > > > Hi!
> > > >
> > > > Today morning my server at home bailed out two times (reboot between):
> > > > Jun 12 07:23:40 zappa
> > > > Jun 12 07:23:40 zappa xfs_force_shutdown(sda7,0x8) called from line
> > > > 1164 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff802f4d8a
> > > > Jun 12 07:23:40 zappa Filesystem "sda7": Corruption of in-memory data
> > > > detected. Shutting down filesystem: sda7
> > > > Jun 12 07:23:40 zappa Please umount the filesystem, and rectify the
> > > > problem(s)
> > Hmm, interesting. I'm seeing the same thing on one of my servers since I
> > upgraded from 2.6.ancient (14 or so) to 2.6.25, while XFS otherwise has
> > been very stable for me over the years:
> > Linux transit5.news.xs4all.nl 126.96.36.199 #1 SMP Wed Jun 11 10:59:10 CEST
> > 2008 x86_64 GNU/Linux
> > Filesystem "sda4": XFS internal error xfs_trans_cancel at line 1163 of
> > file fs/xfs/xfs_trans.c. Caller 0xffffffff880f1315
> > Pid: 3402, comm: diablo Not tainted 188.8.131.52 #1
> This commit in 2.6.26 will probably fix it.
"At ENOSPC, we can get a filesystem shutdown due to a cancelling a dirty
transaction in xfs_mkdir or xfs_create."
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda4 15G 5.1G 9.6G 35% /news
The filesystem is only used for 35%. It might have hit 100% somewhere in
the recent past though (a few reboots ago).
I've applied the patch to 184.108.40.206 just in case, I'll let it run over
the weekend to see what happens.