Re: nfs_statfs: statfs error = 116

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Richard B Johnson <root@chaos.analogic.com> writes:

    >> ERESTARTSYS actually just means that a signal was received
    >> while inside a system call. If this results in a interruption
    >> of that syscall, the kernel is supposed to translate
    >> ERESTARTSYS into the user error EINTR.

     > Hmmm, Maybe I'm getting confused by all the winning-lottery
     > messages, but it's in the syscall specifications for connect()
     > and even
     > fcntl(). http:/www.infran.ru/Techinfo/syscalls/syscalls_43.html

AFAICS that documentation was written in 1994, and refers to Linux
v1.0. We've come a long way since then...

Todays Linux userland is supposed to try to comply with the Single
Unix Specification (see http://www.unix-systems.org/version3/)
whenever possible. ERESTARTSYS is missing altogether from the SUSv3
definitions in <errno.h> (and hence does not appear as a valid return
value for any SUSv3-compliant functions).

Note: the Linux manpages do list ERESTARTSYS as still being returned
by the accept() and syslog() system call. In both those cases,
however, they point out that your libc is supposed to intercept it
before it gets to the user.

     > Also, maybe Linux now claims exclusive ownership and keeps it
     > internal, but some networking software, nfsd and pcnfsd, might
     > not know about that.  I've seen ERESTARTSYS returned from a DOS
     > (actually FAT) file-handle use after a server has crashed and
     > come back on-line.

Linux used to be buggy/non-compliant w.r.t. NFS exporting of FAT
filesystems. I'm not sure if that has been fixed yet.

Cheers,
  Trond