summaryrefslogtreecommitdiff
path: root/Documentation/sysctl/fs.txt
diff options
context:
space:
mode:
authorFederica Teodori <federica.teodori@googlemail.com>2011-03-15 16:12:05 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2011-03-16 10:47:03 -0700
commitca3b78aa1672162f93de90cbf5051edea298a290 (patch)
tree90c62c83356d847286050cc8cdeac47afbed983d /Documentation/sysctl/fs.txt
parentaa4862c38b179646cea73adae41e0078ba05bb60 (diff)
Documentation: file handles are now freed
Since file handles are freed, a little amendment to the documentation Signed-off-by: Federica Teodori <federica.teodori@googlemail.com> Acked-by: Rik van Riel<riel@redhat.com> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/sysctl/fs.txt')
-rw-r--r--Documentation/sysctl/fs.txt17
1 files changed, 8 insertions, 9 deletions
diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt
index 62682500878a..4af0614147ef 100644
--- a/Documentation/sysctl/fs.txt
+++ b/Documentation/sysctl/fs.txt
@@ -88,20 +88,19 @@ you might want to raise the limit.
file-max & file-nr:
-The kernel allocates file handles dynamically, but as yet it
-doesn't free them again.
-
The value in file-max denotes the maximum number of file-
handles that the Linux kernel will allocate. When you get lots
of error messages about running out of file handles, you might
want to increase this limit.
-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.
+Historically,the kernel was able to allocate file handles
+dynamically, but not to free them again. The three values in
+file-nr denote 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.
Attempts to allocate more file descriptors than file-max are
reported with printk, look for "VFS: file-max limit <number>