Christoph Hellwig <[email protected]> wrote:
> > Make it possible to avoid ENFILE checking for kernel specific open files,
> > such as are used by the CacheFiles module.
> >
> > After, for example, tarring up a kernel source tree over the network, the
> > CacheFiles module may easily have 20000+ files open in the backing
> > filesystem, thus causing all non-root processes to be given error ENFILE
> > when they try to open a file, socket, pipe, etc..
>
> No, just increase the limit. The whole point of the limit is to avoid
> resource exaustion. A file doesn't use any less ressources just becuase
> it's opened from kernelspace. In doubt increase the limit or even the
> default limit.
As I saw it, the limit is there to prevent userspace from pinning too many
file resources. Yes, each userspace process is limited by its rlimit, but you
have to multiply that by the number of processes that can be around:
1024 * 32767 > 32 million files
Besides, you say "increase the limit", but there are two problems with that:
(1) Each AFS or NFS _dentry_ retained in the system pins a file in the
backing cache if it's also cached, whether or not it's open. So on my
desktop box, I've got about a million dentries cached. That means I
might also have anything up to a million files open... Except that the
netfs would be denied caching rights on any file beyond the ENFILE limit
- not that that matters, since you wouldn't be able to exec or open
anything if you weren't root - and that might include running su and the
like.
(2) And what should the limit actually _be_? You haven't said. If you
include the cache in the limit, you can at best open ENFILE limit / 2
files on the netfs before you get moaned at by the system... And then
closed files aren't immediately released by the cache, so you can quickly
find yourself backed into a corner...
With this patch, CacheFiles's consumption of files is controlled by the dcache
reclaimer and not by ENFILE, and allocating more files will cause other cache
files to be closed automatically.
The cache can't arbitrarily close backing files for which no userspace file
descriptor remains open: there may be dirty pages, or the file may be mmapped.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
