Bug 54950

Summary: System crawls mounting iso images via loopback
Product: [Retired] Red Hat Linux Reporter: Ron Yorgason <yorgasor>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-10-25 16:02:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ron Yorgason 2001-10-23 17:12:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; SunOS 5.6 sun4u)

Description of problem:
I mounted the RH7.2 iso images via loopback with this command:
mount $1 -r -t iso9660 -o loop $2    where $1 is the iso image and $2 is
the mount point.

All is fine, until I start copying files.  I like to copy all the RPMS into
a separate directory for easy access.  As it copies, the amount of used
memory grows and grows until about 5M, and then the system slows down to a
crawl.  kswapd starts running at about 30% cpu time, and the system load
rises into the 9s.  Swap memory does not get used during this time either. 
Eventually, the copy process finishes and system performance and use of
resources returns to normal.

Note: I did not have this problem with RH7.1

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Mount an ISO image via loopback
2. Start copying data from it
3. When available memory approaches 0, system will slow to a crawl
	

Actual Results:  system performance became incredibly slow until the copy
process eventually completed

Expected Results:  Memory should've been freed as the copy proceeded or
used swap space as necessary.

Additional info:

I have 1.5Gb RAM.  I successfully reproduced this bug with 500Mb of swap
space, and with 2Gb of swap.  Turning swap on or off, or changing swap
device's priority doesn't seem to affect performance, kswapd still sucks
major system resources.

I'm running on an Abit KT7A-Raid with a 1.33Ghz Athlon

Comment 1 Arjan van de Ven 2001-10-23 17:14:49 UTC
Is this with the 2.4.7 or the 2.4.9 kernel ?
The 2.4.9 kernel should behave better in this case

Comment 2 Ron Yorgason 2001-10-25 16:01:54 UTC
This was the 2.4.7 kernel.  After upgrading to 2.4.9 all is well.

Comment 3 Arjan van de Ven 2001-11-04 22:12:01 UTC
"After upgrading to 2.4.9 all is well." -> I'm closing this as "fixed in errata"
as, well, it is. If this comes back or you don't agree with closing as fixed,
please reopen this bug.