From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: Problem Description: System freezes for several seconds while slocate.cron is running. straceing on the updatedb indicate that the occasionally getdents16 took several seconds.When this occured all the user level processes froze for a while.Running a date command every 2 seconds sometimes took 12 seconds to return. It appears that 2.4.18 kernel from kernel.org doesnot exhibit this problem. Is this a known issue? Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1. run slocate.cron 2. check the date 3. Actual Results: User mode processes stalled for several seconds , e.g : top Expected Results: No freeze/ stall Additional info:
how much ram do you have? and what kind of disk system ? (scsi/ide, if IDE, is DMA enabled ?)
It is IDE. We run the default prebuilt kernel on the CD. Is DMA enabled by default?
for supported chipset/bios combinations, IDE DMA is enabled. Use hdparm -i /dev/hda to tell if it's on in your case...
More info about the problem set-up: ->To reproduce the problem faster, we grepped on a large file and pipe it to a file. ->DMA is enabled. 128MB one machine/ 256 MB on the other one. ->Disabling the DMA (hdparm -d0 /dev/hda) makes the problem appear much faster with this set-up. **More info: 1) replacing ext2 with ext3 file system in the red hat kernel make the problem disappear. 2) The problem is not reproducable with original (2.4.18-5) kernel (with ext2 and ext3)
This problem seems to be there with RedHat 8.0 and RedHat 9.0. This bug is still in NEEDINFO state. I am not sure what additional info is waited on?
the latest erratum should have some improvements here; but updatedb still is a bit of a machine pig. Also if ext3 fixes it, great, since ext3 is the default filesystem.
slocate works on EXT2 and not on EXT3. Why this behvior between EXT2 and EXT3. Also we replace RedHat kernel with the kernel from kernel.org fixes the issue even on EXT3. The similar problem is noticed if we access a huge file or tar a huge archive say 200MB instead of using updatedb? Are these problems related? Any idea how to get around this issue? Are you aware of the root cause? Are there any plans to fix this?
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/