> [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).]
I think you _are_ onto something, Rik.
> 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.
My system has "only" 32Mb of ram. (Pentium 133 non mmx - yes, scary
thought, I've seen MMX versions of P133's) on a VX board.
So yes, memory is _very_ tight. I have about 60-80Mb of swap allocated
in two partitions (one on each spindle, priority given to the mostly-idle
drive's swap)
> The inode cache does the following things:
[ ... ]
> - cache inodes of files on disk as referenced by the dcache
Here's some more information I just remembered. Once, only once, when
I had the out of files error with apt-get I managed to get a successful
run by clearing out apt's cache directory of .deb packages. It dropped
the directory from about 50 files or more down to a lock file and a
subdirectory. A run of apt-get then didn't get the error (although it
bombed out later for unrelated reasons). A second run got the error again
so I remembered that I had to mess about in /proc and raise the inode-max.
Also once, just once, raising inode-max had no effect whatsoever and
basically nothing I wanted to do would run. Even vi bombed out with
"too many open files". I tried raising the limits of everything, I
played with all those tunables so that there were enough free and it
was anal in purging - zip, zero, nada. I had to reboot...
Perhaps unrelated, the only other bad problem I've had was going down
the street for an hour with xlock running, and coming back to find no
console whatsoever, and a remote login showed that the X server and
obviously everything else that was running (a couple of rxvt's, XEmacs,
xlock of course) under X vanished without a trace. SVGATextMode couldn't
restore the console (and even 80x25 gave some high-pitched squeals from
the monitor) so I ended up rebooting. Unfortunately nothing was logged
as to why these processes decided to give up on life. I couldn't even
do the C-A-F1 switch to tty1. Had I been thinking straight I probably
would have tried some of the sysrq keys (probably reboot anyhow ;)
just to see if the keyboard wasn't locked up also.
Apart from no console, the box was still functioning fine (go Linux!).
Upon rebooting, one of the swap partitions was trashed (the one with
higher priority - I still haven't gotten around to fixing it). At a
guess I'd say the swap got corrupted somehow and trashed the X server.
Unfortunately I can't really give any more information than that unless
there's something useful written on the swap partition that could be
retrieved somehow if somebody wants a look.
-- Matt- 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/