Messages in this thread | | | Date | Thu, 8 Oct 1998 13:50:52 +0200 (CEST) | From | Rik van Riel <> | Subject | Re: 2.1.124+ /proc/sys/fs/inode-max wrong? |
| |
[Alan, Bill and Stephen, please read on. I think we may have uncovered a bug here (I'm not familiar with the code though, so I may have skipped over something).]
On Thu, 8 Oct 1998, Matthew Hawkins wrote:
> G'day smiley happy people :)
Hmm, that REMinds me of some song...
> I have this problem with 2.1.124, and both .125 pre-patches. It > seems that a lot of programs are refusing to function as they > complain about "too many open files" and so forth. Now I know this > is rubbish as the same programs happen to function fine with 2.0.35, > and 2.1.119. I can reproduce it with Debian's apt, Netscape > Navigator 4.06, and XF86_S3.
> Now what I think seems to be the problem is the default setting of > /proc/sys/fs/inode-max. The documentation from Rik says that this > setting should be 3-4 times greater than file-max. file-max is of > course set to 4096 by default, and to my surprise, so is inode-max. > Increasing inode-max to 16384 seems to get rid of the "too many open > files" problem.
> What's the story here?
The inode cache was using far too much memory on a lot of small machines, so the number of inodes cached was dynamically set on boot dependant on the amount of memory someone has.
The inode cache does the following things: - keep track of open files/sockets/pipes/fifos/other stuff - cache inodes of files on disk as referenced by the dcache
Since the inode cache functions as a slave cache to the file cache, I guess that your machine already used all inode cache entries to cache files cached by the dcache, leaving: - no free entries - no possibility of freeing an entry, since that also has to be done at the dcache level
You seem to have uncovered a bug, raising the number of cached inodes is a workaround, but you can expect a fix real soon (if I identified it correctly, I'm CC:ing some folks in order to check if my suspicion <sp?> is right)...
cheers,
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |