[Top] [All Lists]

Re: xfs problem

To: "Bhanu, Yogesh" <yogesh@xxxxxx>
Subject: Re: xfs problem
From: timothy shimmin <tes@xxxxxxx>
Date: Fri, 07 Oct 2005 19:36:43 +1000
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <8306780C060A7D4790F8BA02CBA1B6910A94BE@sw-rz010.gsf.de>
Organization: sgi
References: <8306780C060A7D4790F8BA02CBA1B6910A94BE@sw-rz010.gsf.de>
Reply-to: tes@xxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
Hi there,

On Wed, 2005-10-05 at 15:40 +0200, Bhanu, Yogesh wrote:
> Hi ,
>     My 3 TB xfs file system spewed few error messages and the whole 
> filesystem has gone offline.
> The system under question is running Suse SLES9 SP2 and is connexted to an  
> IBM T600
> is Dual Opteron with 8 GB RAM (IBM e326).
> The error messages it spewed are .
> -------------cut here----------------------------
>  Filesystem "dm-0": xfs_log_write: reservation ran out. Need to up reservation
> xfs_force_shutdown(dm-0,0x8) called from line 1689 of file fs/xfs/xfs_log.c.  
> Return address = 0xffffffffa01b45e8
> Filesystem "dm-0": Corruption of in-memory data detected.  Shutting down 
> filesystem: dm-0
> Please umount the filesystem, and rectify the problem(s)

Don't know if you can really rectify the problem.
The "run out of reservation" isn't really supposed to happen - it's a

Basically, before a metadata op is peformed we reserve space in the log
for its
associated transaction. The reservation should be enough to handle the
in size, form of the transaction.
We then do the metadata modification and then write (copy)
the transaction into the log buffer. While copying the transaction into
the buffer
we subtract space from our reservation. This message shows that we
either didn't
reserve enough space for the transaction or some other bug has happened
in the code.

I added some code to print out a break-down of the transaction
components, to aid in
tracking down any of these problems. However, this code is turned off by
using a macro, XFS_LOG_RES_DEBUG.
I think I should revisit whether this is a good idea and get a better
idea of
the overhead in turning this macro on all the time.
Otherwise it requires one to be able to reproduce the problem and be in
a position
of being able to build one's own kernel; often not the case.

Sorry, this is no help at the moment.
Your last metadata op with this transaction will not have gone through
to disk.
However, you should be able to remount the filesystem, which will replay
the log
for previous outstanding transactions.


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