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):
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
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
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.
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.
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.