Linux NFS development
 help / color / mirror / Atom feed
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Brian Cowan'" <brian.cowan@hcl-software.com>,
	<linux-nfs@vger.kernel.org>
Subject: RE: Limits to number of files opened by remote hosts over NFSv4?
Date: Tue, 23 Jul 2024 10:22:01 -0700	[thread overview]
Message-ID: <02af01dadd24$d51d7690$7f5863b0$@mindspring.com> (raw)
In-Reply-To: <CAGOwBeW31AThuSLW-aWE0wAz302qaXDaCKCOmmOPjCewB8rkgw@mail.gmail.com>

Any server is likely to have some limit based on the memory use for the open state.

We recently introduced a configuration to limit the number of opens per clientid in nfs-ganesha for comparison, prior to that it was not specifically limited (and the configuration defaults to no limit) other than we would eventually run out of memory.

It's probably good to have a limit, but your case suggests a value in that limit being configurable.

Frank

> -----Original Message-----
> From: Brian Cowan [mailto:brian.cowan@hcl-software.com]
> Sent: Tuesday, July 23, 2024 7:16 AM
> To: linux-nfs@vger.kernel.org
> Subject: Limits to number of files opened by remote hosts over NFSv4?
> 
> I am responsible for supporting an application that opens LOTS of files over NFS
> from a given host, and potentially a few files/host from a LOT of clients. We've
> run into some "interesting" limitations from other OS's when it comes to
> NFSv4...
> 
> Solaris, for example, "only" allows 10K or so files per NFS export to be opened
> over NFSv4. When you have 2500+ client hosts opening files over NFSv4, the
> Solaris NFS server stops responding to "open" requests until an entry in its state
> table is freed up by a file close. Which causes single threaded client processes
> trying to open said files to hang... Luckily we convinced that customer to move
> the clients back to using NFSv3 since they didn't need the additional features of
> V4.
> 
> We're also seeing a potential issue with NetApp filers where opening too many
> files from a single host seems to have issues. We're being told that DataOnTAP
> has a per-client-host limit on the number of files in the Openstate pool (and not
> being told what that limit is...) I say "potential" since the only report is from
> things falling apart after moving from AIX 7.2 to 7.3 (meaning there is a non-
> zero chance that this is actually an AIX NFS issue). In this case, NFSv3 is not an
> option since NFSv4 ACLs are required...
> 
> Anyway, as a result, I'm trying to find out if the Linux NFSv4 server has a limit on
> either total number of files, total number of files per export, or total files per
> host.


  parent reply	other threads:[~2024-07-23 17:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 14:15 Limits to number of files opened by remote hosts over NFSv4? Brian Cowan
2024-07-23 15:00 ` Jeff Layton
2024-07-23 17:22 ` Frank Filz [this message]
2024-07-26 20:41   ` Brian Cowan

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='02af01dadd24$d51d7690$7f5863b0$@mindspring.com' \
    --to=ffilzlnx@mindspring.com \
    --cc=brian.cowan@hcl-software.com \
    --cc=linux-nfs@vger.kernel.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