xfs
[Top] [All Lists]

Re: XFS internal error when NFS client accesses nonexistent inode

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: XFS internal error when NFS client accesses nonexistent inode
From: Mario Becroft <mb@xxxxxxxxxxxxx>
Date: Fri, 02 Jan 2009 12:15:46 +1300
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20090101190039.GA29959@xxxxxxxxxxxxx> (Christoph Hellwig's message of "Thu\, 1 Jan 2009 14\:00\:39 -0500")
References: <87zlicfncr.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20090101171409.GA18020@xxxxxxxxxxxxx> <20090101190039.GA29959@xxxxxxxxxxxxx>
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
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
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.

I realise preserving inode/generation numbers on dump/restore is
probably hard and never going to happen. None of the other Linux
filesystems I have looked at do it either. It would be very, very nice
though... This is a feature I have wanted for ages.

-- 
Mario Becroft <mb@xxxxxxxxxxxxx>

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