[TAG] Hard Drive Access Locking out Application
mso at oz.net
Mon Oct 3 03:50:23 MSD 2005
sklund1 at comcast.net wrote:
>I have been given a new Sony Vaio laptop to use. I have an application developed using the 2.4 kernel with RedHat9. I installed RH9 onto the laptop and rebuilt the stock kernel (2.4.20-8) to include some test code. Everything appears normal, except that twice during the running of my app, the hard drive light goes on for about 40 seconds. This does not happen with my older model Sony Vaio. During this time the mouse and keyboard are locked out. Also the cpu meter/memory meter are frozen. I don't see any error messages in the system log. When the drive light goes out the app continues, apparently without any harm. The "lockouts" occur at the roughly the same place everytime. I have created 2 ramdrives (each 128MB) that store RAM images of filesystems. The first "lockout" appears after the first ramdrive has been populated and the second ramdrive is just begining to be populated. The second "lockout" occurs at a predictable spot during the manipulation of the ram drives.
This is the typical symptom of thrashing, where the computer has so
little free memory or swap space that it has to swap for one process,
then again for the next process. This usually fixes itself five (or
even twenty) minutes later when the kernel unleashes its Terminator and
kills the biggest memory hogs until enough memory is freed.
Are you making the ramdrives to troubleshoot this problem, or are you
using the disk images for something else? 256 MB (128 + 128) is a lot
of memory to take out of general use, especially if your total memory
is 640 MB or less, and you're using Red Hat's default desktop GUI
(which I believe is Gnome- or KDE-based, thus memory-intensive). I
would save the images to a disk file or disk partition instead. If you
have only one partition and for some reason can't put an image of the
filesystem inside the same filesystem (have you looked for an --exclude
option in your image-making program to skip over the destination
file(s)?), you could look at using:
1) cfdisk to verify there are no unallocated sectors on the disk.
2) qtparted or parted to shrink the partition and make another partition.
3) "mount -o loop" to mount a file as if it were a partition, and
putting your destination filesystem on it.
4) your pendrive.
What format are the disk images in, what program are you using to make
them, and what do you need them for? If you just want to diff the two
to see what effect the operation had, perhaps you can just save the:
- filenames ('find' output)
- metadata ('find -dir' output)
- custom metadata ('find | xargs stat -c="FORMAT"')
- complete metadata (custom program using stat(2), which you could
write yourself or I could suggest a Python outline)
- md5sums of the contents ('find | xargs md5sum')
>I have created both a kernel with rd.o as a module (no init.rd file) and with
>rd installed using an init.rd. When I created the kernel with init.rd I specified
>an initial ramdrive of 128Mb. For the kernel with rd.o as module, I use the size spec when doing the insmod call to set the ramdrive capacity. In either case,
>I see the "lockouts" described above.
I'm not sure about ramdisks. Linux has had two or three ramdisk
implementations during its lifetime, and may have more than one now to
choose from. I'd check whether the kind of ramdisk init.rd uses is the
same kind recommended for users. Do you still have to set a ramdisk at
boot time? I'd think that by now you could create one on the fly.
>I have noticed that when I write large files to a USB pendrive or compact flash, there can be quite a delay from umounting the device and "flushing" the output buffers. However, I did not see the the "lockouts" described above on my older (2+ years older) Sony Vaio.
How long is "quite a delay"? Yes, it can takes a significant amount of
time to unmount devices. No, I haven't seen flash devices taking longer
than fifteen seconds. But there may be some devices or computers out
there that do, and there may be nothing you can do about it. Are you
saying that you *do* get lockouts unmounting flash devices on your new
Vaio, or that you've never used flash devices with it?
More information about the TAG