[Top] [All Lists]

Re: XFS internal error when NFS client accesses nonexistent inode

To: Mario Becroft <mb@xxxxxxxxxxxxx>
Subject: Re: XFS internal error when NFS client accesses nonexistent inode
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 1 Jan 2009 18:20:16 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <87ocyqpqhp.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <87zlicfncr.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090101171409.GA18020@xxxxxxxxxxxxx> <20090101190039.GA29959@xxxxxxxxxxxxx> <87ocyqpqhp.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Fri, Jan 02, 2009 at 12:15:46PM +1300, Mario Becroft wrote:
> Christoph Hellwig <hch@xxxxxxxxxxxxx> writes:
> > Btw, you update /proc/sys/fs/xfs/error_level manually?  The corruption
> > test only triggers from a avalue of 5, but 3 is the default.
> I was getting:
> Dec 31 09:12:46 nfs1 kernel: nfsd: non-standard errno: -117
> and in trying to figure out what it meant, I bumped up the XFS debug
> level to 6, which enabled me to see the errors from XFS. Maybe I should
> have just left it alone?
> I should have pointed out that when this happened, the filesystem did
> not actually shut down. So it did not cause any real problems. Should it
> have been shutting down?
> I was mainly just worried that depending on what data it happened to hit

Looking at the code again there indeed aren't shutdowns, just
stacktraces.  So yes, the stacktraces are caused by the higher error
level.  With debug kernels it's still a kernel crash though, but no one
should run debug kernels on their production machines.

> when accessing the nonexistent inode, it might screw things up. If I do
> encounter any shutdowns, I will apply the patch you sent through. Thanks
> for the ultra-fast response.

Please try the second patch which I cc'ed you on as it gives back
the correct error code to the nfs clients.

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