From: Timothy Shimmin <tes@sgi.com>
To: strr-debian@decisionsoft.co.uk
Cc: xfs@oss.sgi.com
Subject: Re: 2.6.24.3 nfs server on xfs keeps producing nfsd: non-standard errno: -117
Date: Thu, 20 Mar 2008 12:09:13 +1100 [thread overview]
Message-ID: <47E1B939.3060008@sgi.com> (raw)
In-Reply-To: <47DFC880.6040403@decisionsoft.co.uk>
Stuart Rowan wrote:
> Timothy Shimmin wrote, on 18/03/08 00:28:
>> Hi Stuart,
>>
>> Stuart Rowan wrote:
>>>
>>> I have *millions* of lines of (>200k per minute according to syslog):
>>> nfsd: non-standard errno: -117
>>> being sent out of dmesg
>>>
>>> Now errno 117 is
>>> #define EUCLEAN 117 /* Structure needs cleaning */
>>>
>> In XFS we mapped EFSCORRUPTED to EUCLEAN as EFSCORRUPTED
>> didn't exist on Linux.
>> However, normally if this error is encountered in XFS then
>> we output an appropriate msg to the syslog.
>> Our default error level is 3 and most reports are rated at 1
>> so should show up I would have thought.
>>
>> --Tim
>>
>>>
>>> xfs_repair -n says the filesystems are clean
>>> xfs_repair has been run multiple times to completion on the
>>> filesystems, all is fine.
>>>
>>> The NFS server is currently in use (indeed the message only starts
>>> once clients connect) and works absolutely fine.
>>>
>>> How do I find out what (if anything) is wrong with my filesystem /
>>> appropriately silence this message?
>>>
>>
> I briefly changed the sysctl fs.xfs.error_level to 6 and then back to 3
>
Good idea (I was thinking about that :-).
Somehow, your subject line referring to 2.6.24 didn't stick in
my brain (that's pretty old).
So I was looking at recent code which I can't see has this error
case from xfs_itobp() (it is now in xfs_imap_to_bp()).
Looking at old code, I see 2 EFSCORRUPTED paths with the following
one triggering at XFS_ERRLEVEL_HIGH (and presumably why you didn't
see it until now) ...
montep |1.198| | /*
montep |1.198| | * Validate the magic number and version of every inode in the buffer
montep |1.198| | * (if DEBUG kernel) or the first inode in the buffer, otherwise.
montep |1.198| | */
nathans |1.303|2.4.x-xfs:slinx:74929a |#ifdef DEBUG
montep |1.198| | ni = BBTOB(imap.im_len) >> mp->m_sb.sb_inodelog;
montep |1.198| |#else
montep |1.198| | ni = 1;
montep |1.198| |#endif
montep |1.198| | for (i = 0; i < ni; i++) {
doucette |1.245|irix6.5f:irix:09146b | int di_ok;
doucette |1.245|irix6.5f:irix:09146b | xfs_dinode_t *dip;
doucette |1.245|irix6.5f:irix:09146b |
lord |1.292|2.4.0-test1-xfs:slinx:65571a| dip = (xfs_dinode_t *)xfs_buf_offset(bp,
montep |1.198| | (i << mp->m_sb.sb_inodelog));
dxm |1.285|2.4.0-test1-xfs:slinx:62350a| di_ok = INT_GET(dip->di_core.di_magic, ARCH_CONVERT) == XFS_DINODE_MAGIC &&
dxm |1.285|2.4.0-test1-xfs:slinx:62350a| XFS_DINODE_GOOD_VERSION(INT_GET(dip->di_core.di_version, ARCH_CONVERT));
overby |1.362|2.4.x-xfs:slinx:136445a | if (unlikely(XFS_TEST_ERROR(!di_ok, mp, XFS_ERRTAG_ITOBP_INOTOBP,
overby |1.362|2.4.x-xfs:slinx:136445a | XFS_RANDOM_ITOBP_INOTOBP))) {
montep |1.198| |#ifdef DEBUG
nathans |1.337|2.4.x-xfs:slinx:119399a | prdev("bad inode magic/vsn daddr 0x%llx #%d (magic=%x)",
nathans |1.337|2.4.x-xfs:slinx:119399a | mp->m_dev, (unsigned long long)imap.im_blkno, i,
nathans |1.303|2.4.x-xfs:slinx:74929a | INT_GET(dip->di_core.di_magic, ARCH_CONVERT));
montep |1.198| |#endif
lord |1.376|2.4.x-xfs:slinx:150747a | XFS_CORRUPTION_ERROR("xfs_itobp", XFS_ERRLEVEL_HIGH,
overby |1.362|2.4.x-xfs:slinx:136445a | mp, dip);
montep |1.198| | xfs_trans_brelse(tp, bp);
sup |1.216| | return XFS_ERROR(EFSCORRUPTED);
montep |1.198| | }
ajs |1.143| | }
So the first inode in the buffer has the wrong magic# or version#.
I'm surprised that this wasn't picked up by repair or check.
--Tim
> It gives the following message and backtrace
>
>> Mar 18 13:35:15 evenlode kernel: nfsd: non-standard errno: -117
>> Mar 18 13:35:15 evenlode kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 Mar 18 13:35:15 evenlode kernel: Filesystem "dm-0": XFS
>> internal error xfs_itobp at line 360 of file fs/xfs/xfs_inode.c.
>> Caller 0xffffffff8821224d
>> Mar 18 13:35:15 evenlode kernel: Pid: 2791, comm: nfsd Not tainted
>> 2.6.24.3-generic #1
>> Mar 18 13:35:15 evenlode kernel: Mar 18 13:35:15 evenlode kernel: Call
>> Trace:
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff8821224d>]
>> :xfs:xfs_iread+0x71/0x1e8
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff8820f784>]
>> :xfs:xfs_itobp+0x141/0x17b
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff8821224d>]
>> :xfs:xfs_iread+0x71/0x1e8
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff8821224d>]
>> :xfs:xfs_iread+0x71/0x1e8
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff8820d7c9>]
>> :xfs:xfs_iget_core+0x352/0x63a
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff8029095f>]
>> alloc_inode+0x152/0x1c2
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff8820db4c>]
>> :xfs:xfs_iget+0x9b/0x13f
>> Mar 18 13:35:15 evenlode kernel: [<ffffffff882243d1>]
>> :xfs:xfs_vget+0x4d/0xbb
>
>
> Does that help?
>
> Thanks,
> Stu.
next prev parent reply other threads:[~2008-03-20 1:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-17 23:27 2.6.24.3 nfs server on xfs keeps producing nfsd: non-standard errno: -117 Stuart Rowan
2008-03-18 0:28 ` Timothy Shimmin
2008-03-18 1:07 ` Stuart Rowan
2008-03-18 13:49 ` Stuart Rowan
2008-03-20 1:09 ` Timothy Shimmin [this message]
2008-03-20 8:25 ` XFS internal error xfs_itobp at line 360 of file fs/xfs/xfs_inode.c. (was Re: 2.6.24.3 nfs server on xfs keeps producing nfsd: non-standard errno: -117) Stuart Rowan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E1B939.3060008@sgi.com \
--to=tes@sgi.com \
--cc=strr-debian@decisionsoft.co.uk \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.