Hi Kevin, On Thursday 01 June 2006 04:00, Kevin Donnelly wrote:
I was moving 1.6Gb of raw DV files via Konqueror from one location to another.
Note: The point of these questions is that it would be very helpful to find the underlying cause of this problem. I can copy a 4.3 GB contiguous file without my system locking up. Reliably. You should enjoy the same. Were you copying the data from one partition to another on the same drive? Or from one drive to another? When I move CD sized and larger files from one partition to another *on the same physical drive* it takes significantly longer than copying the data to another drive. Disk to disk transfer speeds benefit from concurrent reads and writes... one drive reads while the other writes. It's significantly faster. The workload (defined as 100% of the spindle revolutions and actuator steps) is distributed across the two drives. These benefits are missing during data transfers on the same physical drive.
How long did you wait to see if the system would 'gather it's wits?' Quite a while!
Too subjective... how about a rough time estimate, instead? In my experience, you can many times differentiate between a true "lock up" and a "busy system" in the following manner: Move the mouse. If it stays in the same spot but eventually "jumps" to the new location, there's a good chance the system is just "busy" (as in cases during very large file transfers.) In both cases, your keystrokes will appear to be ignored. In one case, they never 'play out' because the system is truly locked up. In the other, the keystrokes are buffered until sufficient resources become available to process them. Also, if you happen to start a very large file transfer when the system is already juggling 'find' and 'sort' during a filesystem indexing operation, you may find yourself waiting for the system to become responsive again for several minutes. Go make some coffee, take a little break and come back to try the mouse move again. I'm only 'hammering down' this point in exhaustive detail because I've helped many people get past the tendancy to expect too much from their system. I am *constantly* reminding my significant other that we're not attached to the net by fiber optics and we're not running mainframes! She has a very 'twitchy' reset button finger and is not a patient person, btw. I doubt you're in that league, but this possibility must be addressed if you want to avoid traumatic filesystem failures in the future.
Were you able to reach a console? (Ctl+Alt+F1 to F6)? Did you check the kernel messages screen (Ctl+Alt+F10)?
No, couldn't reach any of them - the whole system had frozen.
Per the above, keystrokes appear to be buffered for longer periods of time than pointer activity... move the mouse a short distance and observe it for at least a minute or two before you even think about a hard reset.
I don't keep /home on a separate partition, because of possible issues with old config files when I upgrade.
You might think about adopting my 'upgrade in stages' approach. Keep /home on a separate partition, install 'fresh' and use a temporary variation of your 'daily' username. For example, I now have carl93, carlh and carl10-1. Each user environment is 'native' and 'fresh'... not upgraded. 9.3 is my fallback Linux, 10.0 is my 'daily' workspace and 10.1 is in the 'pre-deployment & tweaking' phase. When 10.2 comes out, 9.3 will drop off, 10.0 will takes it's place as my fallback, 10.1 will become my 'daily' and 10.2 takes the 'pre-deployment & tweaking' slot. If this is too much for your tastes, keep a separate /home partition and *backup*... then rename (mv) your existing user directory, i.e. from /home/kev to /home/.kev before the upgrade. If the partition containing your core system takes a dive, your chances of losing data are significantly reduced.
But I do keep all my data in /home/data, which is a symlink to another partition. Except for mail, which I should have symlinked in there, and of course the small database, which a separate /home wouldn't have dealt with anyway.
I've been very lucky... knock knock... but I've also taken reasonable precautions. It only takes one incident of significant data loss to change your perspective. Designing a system to safely backup your data is much less of a chore than recovering that data.
... I think they're both so comprehensively trashed that it'll be pointless. ... I suspect I just have to bite the bullet and reinstall, but thanks anyway.
I concur with this assessment. I hope you can put some of these ideas or similar to good use when you install this time. regards, Carl -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com