Can't kill hung remote CP copy

[Michael Hennebry]

On 14 April 2012 20:25, Michael Hennebry <hennebry at web.cs.ndsu.nodak.edu>wrot$

> Under what circumstance would killing a waiting process
> be worse than a process that should have waited,
> but terminated instead?

On Sat, 14 Apr 2012, Alan Cox wrote:

> When it leaves the system in an unstable state or where corruption could
> follow. Far better then to leave that process stuck unless things sort
> out.
>
> In the case of NFS btw read the mount page for the "soft" and "intr"
> options and also read about umount -f.

Amazing.  Not in a good way.
The corruption would be at the client end, correct?
Is there a reason that the client could not just report back
"taking to long to mount" and leave its data uncorrupted?

Would similar corruption take place if the process had just
termintated itself without waiting for NFS to succeed?

On Sat, 14 Apr 2012, Andy Blanchard wrote:

> Waiting for a timeout implies a reasonably sane state of affairs regarding
> any data in transit, and if the worst has already happened then it's not
> going to make any difference.  Either way, it forces the end user to make a
> hopefully sensible decision about how to reset the device and recover from
> the situation.
>
> If, on the otherhand, you do a soft reset of the device and resume
> transfering data...  Well, think about the garbage that can come out of a
> printer when jobs go wrong, now imagine that being written to a hard disk,
> tape drive, etc.

Don't resume tranfering data as though nothing had gone wrong.
Possibly don't resume transfering data at all.
Unless the human says otherwise,
assume one will not be allowed to transfer any more data on that channel.

-- 
Michael   hennebry at web.cs.ndsu.NoDak.edu
"On Monday, I'm gonna have to tell my kindergarten class,
whom I teach not to run with scissors,
that my fiance ran me through with a broadsword."  --  Lily