linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: akpm@osdl.org, aviro@redhat.com, nfsv4@linux-nfs.org,
	linux-kernel@vger.kernel.org, torvalds@osdl.org,
	linux-cachefs@redhat.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 3/7] FS-Cache: Avoid ENFILE checking for kernel-specific open files
Date: Thu, 20 Apr 2006 19:06:42 +0100	[thread overview]
Message-ID: <22114.1145556402@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <20060420171857.GA21659@infradead.org>

Christoph Hellwig <hch@infradead.org> 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

  parent reply	other threads:[~2006-04-20 18:06 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-20 16:59 [PATCH 1/7] FS-Cache: Provide a filesystem-specific sync'able page bit David Howells
2006-04-20 16:59 ` [PATCH 2/7] FS-Cache: Add notification of page becoming writable to VMA ops David Howells
2006-04-20 17:40   ` Zach Brown
2006-04-20 18:27     ` Anton Altaparmakov
2006-04-20 16:59 ` [PATCH 3/7] FS-Cache: Avoid ENFILE checking for kernel-specific open files David Howells
2006-04-20 17:18   ` Christoph Hellwig
2006-04-20 18:06   ` David Howells [this message]
2006-04-21  0:11     ` Andrew Morton
2006-04-21 10:57     ` David Howells
2006-04-21  0:07   ` Andrew Morton
2006-04-21 12:33   ` David Howells
2006-04-21 18:22     ` Andrew Morton
2006-04-21 19:29     ` David Howells
2006-04-20 16:59 ` [PATCH 4/7] FS-Cache: Export find_get_pages() David Howells
2006-04-20 17:19   ` Christoph Hellwig
2006-04-20 17:45   ` David Howells
2006-04-21  0:15     ` Andrew Morton
2006-04-21 13:02     ` David Howells
2006-04-20 16:59 ` [PATCH 5/7] FS-Cache: Generic filesystem caching facility David Howells
2006-04-21  0:46   ` Andrew Morton
2006-04-21 14:15   ` David Howells
2006-04-21 18:38     ` Andrew Morton
2006-04-21 19:33     ` David Howells
2006-04-20 16:59 ` [PATCH 6/7] FS-Cache: Make kAFS use FS-Cache David Howells
2006-04-20 16:59 ` [PATCH 7/7] FS-Cache: CacheFiles: A cache that backs onto a mounted filesystem David Howells
2006-04-21  0:57   ` Andrew Morton
2006-04-21  1:16   ` Andrew Morton
2006-04-21 14:49   ` David Howells
2006-04-21  0:12 ` [PATCH 1/7] FS-Cache: Provide a filesystem-specific sync'able page bit Andrew Morton
2006-04-21 10:22 ` David Howells
2006-04-21 10:33   ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22114.1145556402@warthog.cambridge.redhat.com \
    --to=dhowells@redhat.com \
    --cc=akpm@osdl.org \
    --cc=aviro@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).