Oh dear, that isnt going to work. close() needs to be fixed to behave like
SunOS/Solaris where it sleeps until the close completes (Also there is
an EWFLUSH (I think thats the name) close() return on some systems.
It does sleep until the close completes, look at it. As for the
EWFLUSH buisness, this is another issue.
Look at what most applications do if they get an error return value.
They cannot be woken on signals, it's a mess, think about it. There
is one small chance to make it work correctly, using ERESTARTNOHAND.
Ok, let's say you've taken care of that, next step is you have to fix
the whole close () path to be able to undo it's state if nfs close
operations return some non-zero value back on down.
Right now you break soft mounts, you break mount to a down host and an
interesting collection of stuff. I'll go undo that hack now I know its just
a botch around a real bug.
Out of curiosity, how _did_ 2.0.x behave when pending writes of NFS
data were done and the remote end failed or a signal was received?
Did it return back to the user with ERESTARTSYS or similar? I doubt
it.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html