Re: Can't kill hung remote CP copy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14 April 2012 20:25, Michael Hennebry <hennebry@xxxxxxxxxxxxxxxxxxxxx>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@xxxxxxxxxxxxxxxxxxxxx
"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
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org


[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux