Bug 54950 - System crawls mounting iso images via loopback
System crawls mounting iso images via loopback
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-10-23 13:12 EDT by Ron Yorgason
Modified: 2007-04-18 12:37 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Ron Yorgason 2001-10-23 13:12:01 EDT
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 13:14:49 EDT
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 12:01:54 EDT
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 17:12:01 EST
"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.