From ca3b78aa1672162f93de90cbf5051edea298a290 Mon Sep 17 00:00:00 2001 From: Federica Teodori Date: Tue, 15 Mar 2011 16:12:05 -0700 Subject: [PATCH] Documentation: file handles are now freed Since file handles are freed, a little amendment to the documentation Signed-off-by: Federica Teodori Acked-by: Rik van Riel Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/sysctl/fs.txt | 17 ++++++++--------- 1 file 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 -- 2.30.2