On 05/18/2011 01:15 PM, John Andersen wrote:
On 5/17/2011 10:34 PM, auxsvr@gmail.com wrote:
Regardless of the known kio_slave problems when moving files, your description indicates that there is a problem at the hardware/driver level, since errors are mentioned by the kernel SCSI layer.
Well, these errors are NEVER triggered at the command line cp operation, and the copy always completes uneventfully.
As I mentioned, I ran the test several times, tailing the logs all the while.
So removing the kio slaves from the equation eliminates the problem. That would indicate there is nothing wrong with the hardware, and indeed it has been operating fine for over a year, and has been connected to several different linux machines during that time.
My sense is that kio has some timing that causes it to trigger a scsi bus reset when the drive is busy buffering a large read operation on a fragmented file system. Once it gets the above mentioned abort, it will never resume.
How many kio slaves are spawned to do the copying? I would suspect that the problem is not in the hardware but that the number of slaves spawned are overloading the io system and likely the hardware as well. It seems that certain apps spawn lots of kio slaves. Akregator does this and all that io firepower chokes a slow connection to death. Some others spawn so many that the wm crashes & dies. It is possible to have several apps spawn so many kio slaves simultaneously that they virtually stop the system dead. None of these apps allow the user to limit the number of slaves spawned and if you kill any the app just spawns new ones to replace them. jd -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org