Description of problem: The definition of /proc/sys/fs/file-nr in the proc(5) man page was valid for the Linux 2.4.x kernel, but it is stale for 2.6. An updated definition can be found in /usr/share/doc/kernel-doc-2.6.18/Documentation/filesystems/proc.txt It currently reads: /proc/sys/fs/file-nr This (read-only) file gives the number of files presently opened. It contains three numbers: The number of allocated file handles, the number of free file handles and the maximum number of file handles. The kernel allocates file handles dynamically, but it doesn’t free them again. If the number of allocated files is close to the maximum, you should consider increasing the maximum. When the number of free file handles is large, you’ve encountered a peak in your usage of file handles and you probably don’t need to increase the maximum. Copying from filesystems/proc.txt, it should read something like: /proc/sys/fs/file-nr Historically, the three values in file-nr denoted the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. Linux 2.6 always reports 0 as the number of free file handles -- this is not an error, it just means that the number of allocated file handles exactly matches the number of used file handles. Version-Release number of selected component (if applicable): man-pages-2.39-12.el5 Additional info: The description in /usr/share/doc/kernel-doc-2.6.18/Documentation/sysctl/fs.txt is also stale.
Created attachment 340786 [details] patch for proc(5) man page
See bug 497200 for the sysctl/fs.txt definition.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1574.html
The problem with the Red Hat patch is that it loses (quite a lot of) information. I've applied the patch below to upstream: diff --git a/man5/proc.5 b/man5/proc.5 index 30818d2..93be9eb 100644 --- a/man5/proc.5 +++ b/man5/proc.5 @@ -2270,16 +2270,21 @@ can override the limit. .TP .I /proc/sys/fs/file-nr -This (read-only) file gives the number of files presently opened. -It contains three numbers: the number of allocated file handles; +This (read-only) file contains three numbers: +the number of allocated file handles +(i.e., the number of files presently opened); the number of free file handles; and the maximum number of file handles. -The kernel allocates file handles dynamically, but it -doesn't free them again. -If the number of allocated files is close to the +If the number of allocated file handles is close to the maximum, you should consider increasing the maximum. -When the number of free file handles is -large, you've encountered a peak in your usage of file -handles and you probably don't need to increase the maximum. +Before Linux 2.6, +the kernel allocated file handles dynamically, +but it didn't free them again. +Instead the free file handles were kept in a list for reallocation; +the "free file handles" value indicates the size of that list. +A large number of free file handles indicates that there was +a past peak in the usage of open file handles. +Since Linux 2.6, the kernel does deallocate freed file handles, +and the "free file handles" value is always zero. .TP .I /proc/sys/fs/inode-max This file contains the maximum number of in-memory inodes.