Ian Dowse wrote:
> In message <200307090913.h699DnK3053575@lurza.secnetix.de>, Oliver Fromme writes:
> > It is my understanding that the interruptible flag has only
> > an effect when a signal is delivered to a process which is
> > blocked on NFS I/O. Or am I wrong?

> Yes, the interruptible flag should only have an effect when the
> process receives a signal while waiting on an NFS response. Maybe
> it is possible that the progess is sending itself a signal? NFS

Uhm. Well. It's a collection of Linux java processes
(about 30 of them), and the load on them is very erratic,
so it's a bit diffcult to find out what they do. I guess
it's very possible that they send such signals to each
other or to themselves. In the truss output of some of
the processes there are calls to linux_rt_sigprocmask()
and linux_kill().

I've also seen "SIGNAL 32" in the truss output, which
seems strange to me, because there is no such signal
number in . Well, maybe it's a Linux
signal. I also see linux_kill(0xf6b3,0x20), and 0x20
is 32. But I guess the NFS code does not check for
signal 32. Or maybe the NFS code has a bug with non-
standard signal numbers >= 32?

> If you are using the -s/soft option then that is quite different -
> there are well-known effects where an unusually long delay from
> the server can trigger occasional EINTR errors.

Nope, I never use the "soft" option. I'm well aware
that soft mounts are evil.

I have now removed the intr flag from the mount. Now
the only thing I can do is wait ... If the problem
doesn't occur for a few days, I regard it to be solved.

Thanks a lot to all of you!


Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
freebsd-fs@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"