NetBSD Problem Report #46132

From dholland@macaran.localdomain  Sat Mar  3 01:00:07 2012
Return-Path: <dholland@macaran.localdomain>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 2EB5B63DFA6
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  3 Mar 2012 01:00:07 +0000 (UTC)
Message-Id: <20120303010015.255C16E217@macaran.localdomain>
Date: Fri,  2 Mar 2012 20:00:15 -0500 (EST)
From: dholland@eecs.harvard.edu
Reply-To: dholland@eecs.harvard.edu
To: gnats-bugs@gnats.NetBSD.org
Subject: spurious EINTRs from nfs
X-Send-Pr-Version: 3.95

>Number:         46132
>Category:       kern
>Synopsis:       spurious EINTRs from nfs
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 03 01:05:00 +0000 2012
>Last-Modified:  Sun Jan 01 01:20:01 +0000 2017
>Originator:     David A. Holland
>Release:        NetBSD 6.99.3 (20120227)
>Organization:
>Environment:
System: NetBSD macaran 6.99.3 NetBSD 6.99.3 (MACARAN) #11: Mon Feb 27 17:12:40 EST 2012 dholland@macaran:/usr/src/sys/arch/amd64/compile/MACARAN amd64
Architecture: x86_64
Machine: amd64
>Description:

I just saw this:

macaran% rm -r vnlock-real
rm: vnlock-real/.hg/store/data/sys/dist/acpica/acmacros.h.i: Interrupted system call
rm: vnlock-real/.hg/store/data/sys/dist/acpica/acnames.h.i: Interrupted system call
rm: vnlock-real/.hg/store/data/sys/dist/acpica: Directory not empty
rm: vnlock-real/.hg/store/data/sys/dist: Directory not empty
rm: vnlock-real/.hg/store/data/sys: Directory not empty
rm: vnlock-real/.hg/store/data: Directory not empty
rm: vnlock-real/.hg/store: Directory not empty
rm: vnlock-real/.hg: Directory not empty
rm: vnlock-real: Directory not empty
Exit 1
macaran% 

This was an old NetBSD source tree stored in Mercurial, on an NFS
volume stored on a NetApp filer across a routed TCP connection. The
system wasn't *entirely* idle while this was going on, but I'm certain
nothing was sending signals to rm and nothing else was using the same
NFS volume locally either.

The thing that sets this particular rm -r apart from others is that
this tree hadn't been touched in years; it took a long time to delete
and I expect the filer had moved the data to the boneyard in some
fashion.

So I'm guessing there's something in the NFS client code that timed
out and that these timeouts are producing EINTR instead of a sensible
error condition.

>How-To-Repeat:

Probably can't be repeated on demand. I do have some more comparably
old trees I found today, but I'd just as soon nuke them now rather
than save them for testing.

>Fix:
torches and pitchforks?

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/46132: spurious EINTRs from nfs
Date: Sun, 1 Jan 2017 01:17:47 +0000

 On Sat, Mar 03, 2012 at 01:05:00AM +0000, dholland@eecs.harvard.edu wrote:
  > macaran% rm -r vnlock-real
  > rm: vnlock-real/.hg/store/data/sys/dist/acpica/acmacros.h.i: Interrupted system call

 I still see this from time to time, if anything more than in 2012.

 It remains unclear whether it's really a timeout masquerading as a
 signal, or a filer problem, or what.

 (because the performance of our department infrastructure seems to be
 worse every year, probably as an excuse to eventually outsource
 everything)

  > >Fix:
  > torches and pitchforks?

 yes please :-)

 -- 
 David A. Holland
 dholland@netbsd.org

Home	PR Database Search