Bug 54950 - System crawls mounting iso images via loopback
Summary: System crawls mounting iso images via loopback
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-23 17:12 UTC by Ron Yorgason
Modified: 2007-04-18 16:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-25 16:02:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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:

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.

Note You need to log in before you can comment on or make changes to this bug.