Bug 64152 - ext3 file system reset causes loss of all but 4 meg available memory
Summary: ext3 file system reset causes loss of all but 4 meg available memory
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2002-04-26 17:26 UTC by Steve Wells
Modified: 2007-04-18 16:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-27 19:59:07 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 Steve Wells 2002-04-26 17:26:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
Allow ext3 file system to restart in file check mode.  When file check & 
restart is complete, top indicates only 4 megabytes of physical memory is 
available & swap file memory is being utilized instead.

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

How reproducible:

Steps to Reproduce:
1.configure ext3 file system & start system (with 128 meg physical memory) 
clean from power up
2.verify using top that available memory is 60-80+ megs free
3.run "shutdown - F -r now" 
4.when system restarts, allow file check to be performed.
5.after system is up, log on and run top - verify that only 4 meg of physical 
memory is free and system swap file is being used.

Actual Results:  ext3 reset operation reportedly consumes significant amounts 
of memory which is never returned to operating system.

Expected Results:  ext3 would return memory to operating system following reset 

Additional info:

This problem seems to occur whenever system goes through file reset operation, 
regardless of whether it's initiated via shutdown command or by resetting box 

Comment 1 Stephen Tweedie 2002-04-28 17:34:31 UTC
What is a "file reset operation"?  I assume you mean a "fsck" filesystem check.  

Yes, that will use all the memory in the system for caching.  No, that memory
will not be returned once fsck completes --- the whole point of a cache is that
until we need to use that memory for something else, we might as well keep the
contents of the cache around just in case they turn out to be useful.  The
memory that is in use should be returned as soon as anything else in the system
needs it.  Seeing no free memory in top just indicates that the cache is
performing as designed.

Comment 2 Steve Wells 2002-04-29 16:07:21 UTC
Presumption that memory is being returned by cache once other apps need is 
incorrect; in this case we are running Java VM and (according to Top) is then 
loaded using considerable OS swap system space, rather than physical memory, 
which it will when loaded without having previously run fsck.

Comment 3 Stephen Tweedie 2002-04-30 14:52:34 UTC
Process memory which was swapped out during the fsck run may quite legitimately
remain on swap afterwards if nothing needs it paged back into memory.  If the
swapped memory _is_ needed, but is only touched for read access, then the copy
in the swap area on disk remains valid and is not removed.  There are all sorts
of reasons why swap may remain in use afterwards.

If you see excessive swap activity take place for a prolonged period after the
fsck, then that might be a performance problem.  The mere presence of a certain
amount of swapped page in "free" output is not a problem.

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