sidekick:~# for one in /proc/sys/fs/*; do echo $one : `cat $one`; done
/proc/sys/fs/dentry-state : 0 96658 45 0 0 0
/proc/sys/fs/dquot-max : 0
/proc/sys/fs/dquot-nr : 0 0
/proc/sys/fs/file-max : 7168
/proc/sys/fs/file-nr : 4860 3113 7168
/proc/sys/fs/inode-max : 20480
/proc/sys/fs/inode-nr : 1268624 3
/proc/sys/fs/inode-state : 1268624 9 1 0 0 0 0
/proc/sys/fs/super-max : 256
/proc/sys/fs/super-nr : 6
Does the above fall into the same category? I'm talking about the inode-nr
and inode-state numbers - they are ridiculously big to me. The numbers for
inode-max and file-max are slightly bumped up. Kernel is 2.2.1. More details
uppon request :).
Alexander Viro wrote:
> On Wed, 3 Feb 1999, Oleg Drokin wrote:
>
> > Seems that inode cache that grows in inode.c:419 is never shrinked.
>
> What??? Wait... it's grow_inodes() and it looks like we never shrink the
> damned icache again. Looks like it was always so with possible exception
> of 2.1.36-2.1.42 when we used slab instead of bare pages. Damn. It's not a
> leak per se - we just never shrink icache. Now, the fact that you managed
> to grow it that large may mean that there is an inode leak, but that's
> another story. What is the number of dirty inodes, BTW? They can't be
> reused until they are cleaned.
Thanks!
-- Tomek,
"Office'97, Windows'98 - every Microsoft product has an expiration date."
-
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/