Commit bcadbbd4c896c80c263c35ce94b763e5ff58cecd

Authored by Xiaotian Feng
Committed by Linus Torvalds
1 parent 16c01b20ae

Documentation: update stale definition of file-nr in fs.txt

In "documentation: update Documentation/filesystem/proc.txt and
Documentation/sysctls" (commit 760df93ec) we merged /proc/sys/fs
documentation in Documentation/sysctl/fs.txt and
Documentation/filesystem/proc.txt, but stale file-nr definition
remained.

This patch adds back the right fs-nr definition for 2.6 kernel.

Signed-off-by: Xiaotian Feng<dfeng@redhat.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Showing 1 changed file with 10 additions and 7 deletions Side-by-side Diff

Documentation/sysctl/fs.txt
... ... @@ -96,13 +96,16 @@
96 96 of error messages about running out of file handles, you might
97 97 want to increase this limit.
98 98  
99   -The three values in file-nr denote the number of allocated
100   -file handles, the number of unused file handles and the maximum
101   -number of file handles. When the allocated file handles come
102   -close to the maximum, but the number of unused file handles is
103   -significantly greater than 0, you've encountered a peak in your
104   -usage of file handles and you don't need to increase the maximum.
  99 +Historically, the three values in file-nr denoted the number of
  100 +allocated file handles, the number of allocated but unused file
  101 +handles, and the maximum number of file handles. Linux 2.6 always
  102 +reports 0 as the number of free file handles -- this is not an
  103 +error, it just means that the number of allocated file handles
  104 +exactly matches the number of used file handles.
105 105  
  106 +Attempts to allocate more file descriptors than file-max are
  107 +reported with printk, look for "VFS: file-max limit <number>
  108 +reached".
106 109 ==============================================================
107 110  
108 111 nr_open: