Red Hat Bugzilla – Bug 64152
ext3 file system reset causes loss of all but 4 meg available memory
Last modified: 2007-04-18 12:42:20 EDT
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: Always 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 operations 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 inadvertently.
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.