[TAG] Hard Drive Access Locking out Application

[Mike Orr]

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?