Michael Brusser <michael@synchronicity.com> writes:
> > Michael Brusser <michael@synchronicity.com> writes:
> > > 2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks:
> > > Interrupted system call
> >
> > Hmm. I found this hard to believe at first, but indeed my local man
> > pages for read() and write() say they can return EINTR if interrupted
> > by a signal. This may depend on the filesystem in use (are you using
> > NFS?)
The traditional unix semantics are the read/write my return EINTR if
interrupted -- but that that would only EVER happen for network connections.
The traditional semantics are that it would NEVER happen on disk i/o. BSD
kernels at least, and probably all unix kernels, do an uninterruptible sleep
on disk accesses, hence the dreaded "D" in ps listings.
> Yes, we use NFS. Many of our customers use it as well.
Normally NFS guarantees the traditional unix semantics.
Unless you're using either "soft" or "intr" options.
If you are, well, stop.
If you use "intr" then this type of thing can happen. Lots of programs assume
the unix semantics for disk accesses. You can get all kinds of bugs when
they're violated.
If you use "soft" then the consequences can be much much worse. If your
fileserver were to reboot you could silently lose disk writes corrupting your
database.
--
greg