Trond Myklebust wrote:
> I would certainly be good if we could delegation the documentation. But I
> couldn't find anything in signal(7) that seemed particularly relevant. Which
> bit were you thinking of?
>
The table which lists the posix signals, and which indicates whether they
are fatal not (i.e. what ‘action’ they cause). The same page also
explains signal blocking and signal handling, which could also be
helpful..
This seems the relevant part to me, assuming nfs system calls are considered
"slow":
* read(2), readv(2), write(2), writev(2), and ioctl(2) calls on
"slow" devices. A "slow" device is one where the I/O call may
block for an indefinite time, for example, a terminal, pipe, or
socket. (A disk is not a slow device according to this defini‐
tion.) If an I/O call on a slow device has already transferred
some data by the time it is interrupted by a signal handler, then
the call will return a success status (normally, the number of
bytes transferred).
Here's Neil's description:
>>> "A process that is waiting for a reply for an NFS server can be killed
>>> by any signal which would normally kill the process. If a signal would not
>>> normally kill the process (i.e. it is caught or ignored) then that signal
>>> will not abort and NFS request".
So assuming nfs system calls honor the SA_RESTART flag, I think these
behaviors are the same?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
