NFS strategy for large number of file opens

NFS strategy for large number of file opens

[Shyam Prasad N]

Hi all,

I'm starting this email thread to understand how NFS deals (or plans
to deal with) workloads that serially do open/close calls to a large
number of files in a directory? Think about a use case of tar of Linux
kernel source code on NFS shares.

AFAIK, local filesystems fare well for this workload compared to
network filesystems, as file opens are local, and file state is
maintained locally. For network filesystems, each open needs to go
over the wire to the server.

Has there been any proposals to improve perf for such workloads?
Could there be possible extensions to directory delegations, that
could allow the client to make opens async and batch them together to
the server in the background? IMO, the challenge is that such open
calls can fail. But can the clients be enabled to do many of these
failure checks (for example, the client could be allocated quota for
how many files it can create, be allowed to cache file permissions by
delegating them etc.)?

Looking forward to the responses. Thanks in advance.

-- 
Regards,
Shyam

Re: NFS strategy for large number of file opens

[Jeff Layton]

On Mon, 2026-09-07 at 17:23 +0530, Shyam Prasad N wrote:
> Hi all,
> 
> I'm starting this email thread to understand how NFS deals (or plans
> to deal with) workloads that serially do open/close calls to a large
> number of files in a directory? Think about a use case of tar of Linux
> kernel source code on NFS shares.
> 
> AFAIK, local filesystems fare well for this workload compared to
> network filesystems, as file opens are local, and file state is
> maintained locally. For network filesystems, each open needs to go
> over the wire to the server.
>
> Has there been any proposals to improve perf for such workloads?
> Could there be possible extensions to directory delegations, that
> could allow the client to make opens async and batch them together to
> the server in the background? IMO, the challenge is that such open
> calls can fail. But can the clients be enabled to do many of these
> failure checks (for example, the client could be allocated quota for
> how many files it can create, be allowed to cache file permissions by
> delegating them etc.)?
> 
> Looking forward to the responses. Thanks in advance.

You should resend this and cc linux-nfs@vger.kernel.org.

The big problem for untar workloads is that they are serialized at the
VFS layer on the client. Neil Brown has been working on changing that.
-- 
Jeff Layton <jlayton@kernel.org>

Re: NFS strategy for large number of file opens

[Shyam Prasad N]

On Tue, Sep 8, 2026 at 3:24 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Mon, 2026-09-07 at 17:23 +0530, Shyam Prasad N wrote:
> > Hi all,
> >
> > I'm starting this email thread to understand how NFS deals (or plans
> > to deal with) workloads that serially do open/close calls to a large
> > number of files in a directory? Think about a use case of tar of Linux
> > kernel source code on NFS shares.
> >
> > AFAIK, local filesystems fare well for this workload compared to
> > network filesystems, as file opens are local, and file state is
> > maintained locally. For network filesystems, each open needs to go
> > over the wire to the server.
> >
> > Has there been any proposals to improve perf for such workloads?
> > Could there be possible extensions to directory delegations, that
> > could allow the client to make opens async and batch them together to
> > the server in the background? IMO, the challenge is that such open
> > calls can fail. But can the clients be enabled to do many of these
> > failure checks (for example, the client could be allocated quota for
> > how many files it can create, be allowed to cache file permissions by
> > delegating them etc.)?
> >
> > Looking forward to the responses. Thanks in advance.
>
> You should resend this and cc linux-nfs@vger.kernel.org.

Hi Jeff,

linux-cifs mailing list is already in the cc. :)

>
> The big problem for untar workloads is that they are serialized at the
> VFS layer on the client. Neil Brown has been working on changing that.

Has this been discussed in the mailing list? Could you point me to
that discussion?

> --
> Jeff Layton <jlayton@kernel.org>



-- 
Regards,
Shyam

Re: NFS strategy for large number of file opens

[Jeff Layton]

On Wed, 2026-09-09 at 15:05 +0530, Shyam Prasad N wrote:
> On Tue, Sep 8, 2026 at 3:24 PM Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > On Mon, 2026-09-07 at 17:23 +0530, Shyam Prasad N wrote:
> > > Hi all,
> > > 
> > > I'm starting this email thread to understand how NFS deals (or plans
> > > to deal with) workloads that serially do open/close calls to a large
> > > number of files in a directory? Think about a use case of tar of Linux
> > > kernel source code on NFS shares.
> > > 
> > > AFAIK, local filesystems fare well for this workload compared to
> > > network filesystems, as file opens are local, and file state is
> > > maintained locally. For network filesystems, each open needs to go
> > > over the wire to the server.
> > > 
> > > Has there been any proposals to improve perf for such workloads?
> > > Could there be possible extensions to directory delegations, that
> > > could allow the client to make opens async and batch them together to
> > > the server in the background? IMO, the challenge is that such open
> > > calls can fail. But can the clients be enabled to do many of these
> > > failure checks (for example, the client could be allocated quota for
> > > how many files it can create, be allowed to cache file permissions by
> > > delegating them etc.)?
> > > 
> > > Looking forward to the responses. Thanks in advance.
> > 
> > You should resend this and cc linux-nfs@vger.kernel.org.
> 
> Hi Jeff,
> 
> linux-cifs mailing list is already in the cc. :)
> 

My mistake!

> > 
> > The big problem for untar workloads is that they are serialized at the
> > VFS layer on the client. Neil Brown has been working on changing that.
> 
> Has this been discussed in the mailing list? Could you point me to
> that discussion?
> 
> 

He has some preparatory patches here:

https://lore.kernel.org/linux-fsdevel/20260904215142.1060510-1-neilb@ownmail.net/

...but that might not help with untar workloads after all. What Neil's
set would enable is parallel creates in the same directory, but untar
is usually single-threaded and so you might be stuck waiting on round
trip delays anyway.

If you're interested in speeding up untar-style workloads, you might
want to check out the async create code we added to the Ceph client
several years ago.

Basically, the Ceph MDS issues a swath of inode numbers to the client
when it has appropriate caps on the directory, and it can then do
creates locally and trickle them back out to the MDS over time.

Here are some slides from a few years ago:

https://www.usenix.org/sites/default/files/conference/protected-files/vault20_slides_layton.pdf

Cheers,
-- 
Jeff Layton <jlayton@kernel.org>