From: Bryan Schumaker <bjschuma@netapp.com>
To: "Myklebust, Trond" <Trond.Myklebust@netapp.com>
Cc: Frank Nicholas <frank@nicholasfamilycentral.com>,
Jim Rees <rees@umich.edu>,
"Schumaker, Bryan" <Bryan.Schumaker@netapp.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"bfields@fieldses.org" <bfields@fieldses.org>
Subject: Re: kernel BUG at fs/nfs/idmap.c:684!
Date: Tue, 28 Aug 2012 14:08:14 -0400 [thread overview]
Message-ID: <503D090E.3060505@netapp.com> (raw)
In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA908F755A3@SACEXCMBX04-PRD.hq.netapp.com>
On 08/28/2012 02:06 PM, Myklebust, Trond wrote:
> On Tue, 2012-08-28 at 14:01 -0400, Frank Nicholas wrote:
>> On Aug 28, 2012, at 1:46 PM, Frank Nicholas <frank@nicholasfamilycentral.com> wrote:
>>
>>>
>>> On Aug 28, 2012, at 1:43 PM, Jim Rees <rees@umich.edu> wrote:
>>>
>>>> Frank Nicholas wrote:
>>>>
>>>> Thanks for the quick reply.
>>>>
>>>> The patches applied cleanly. I've rebuilt my kernel. The reboot will
>>>> have to wait until I have physical access to the machine to do a hard
>>>> power off… Unless you know of some way to clean up the hung NFS items so
>>>> I can do a reboot. Currently if I try a 'shutdown -r now', the system
>>>> hangs on trying to clean up the NFS items.
>>>>
>>>> Did you try "reboot -f"?
>>>
>>>
>>> Yep - Remembering back to the old Solaris days, 'sync ; sync ; sync ; reboot -f'.
>>>
>>> That got it. The 'emerge --sync' ran fine & the VM's that are using stores from NFS shares are working ok. So far no NFS issues.
>>>
>>> Thanks.
>>>
>>
>> After the reboot, doing an 'emerge --sync' & starting a VM, I have the following in my syslog:
>>
>> Aug 28 13:52:09 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:52:19 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:52:19 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:52:19 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:52:19 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:52:19 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:52:19 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:52:19 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:54:05 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:54:05 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:54:05 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:54:05 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:54:05 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>> Aug 28 13:54:05 martin rpc.idmapd[2899]: nfscb: write(/var/lib/nfs/rpc_pipefs//nfs/clnt0/idmap): No space left on device
>>
>> I believe each group of these (by date/time) were when I did the 'emerge --sync' & when I started the VM who has a virtual drive on an NFS share. I don't remember seeing anything like this before. Is this due to the patch? Should I be concerned? I know this is a pipe, but I've confirmed there is plenty of free disk space everywhere. The pipe does exist on the file system. There is plenty of free memory. Any suggestions?
>
> An early version of those patches did indeed cause problems such as the
> above. Are you sure that you applied the patches that actually went
> upstream in
No, I don't think he did. I forgot you fixed up a few things, so I sent him the last copy I had.
- Bryan
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=c5066945b7ea346a11424dbeb7830b7d7d00c206
> and
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=12dfd080556124088ed61a292184947711b46cbe
>
next prev parent reply other threads:[~2012-08-28 18:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-28 12:42 kernel BUG at fs/nfs/idmap.c:684! Frank Nicholas
2012-08-28 12:49 ` Frank Nicholas
2012-08-28 14:43 ` Bryan Schumaker
2012-08-28 17:05 ` Frank Nicholas
2012-08-28 17:43 ` Jim Rees
2012-08-28 17:46 ` Frank Nicholas
2012-08-28 18:01 ` Frank Nicholas
2012-08-28 18:05 ` Bryan Schumaker
2012-08-28 18:06 ` Myklebust, Trond
2012-08-28 18:08 ` Bryan Schumaker [this message]
2012-08-28 18:47 ` Frank Nicholas
2012-08-28 19:55 ` Frank Nicholas
2012-08-28 20:05 ` Bryan Schumaker
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=503D090E.3060505@netapp.com \
--to=bjschuma@netapp.com \
--cc=Bryan.Schumaker@netapp.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=frank@nicholasfamilycentral.com \
--cc=linux-nfs@vger.kernel.org \
--cc=rees@umich.edu \
/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.