NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/46132: spurious EINTRs from nfs



>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
>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?



Home | Main Index | Thread Index | Old Index