All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ronnie Sahlberg <lsahlber@redhat.com>
To: linux-cifs <linux-cifs@vger.kernel.org>
Cc: Steve French <smfrench@gmail.com>
Subject: [PATCH 0/3 V1] cifs: cache the directory content for shroot
Date: Mon,  5 Oct 2020 12:37:51 +1000	[thread overview]
Message-ID: <20201005023754.13604-1-lsahlber@redhat.com> (raw)

Steve, Aurelien, List

Please find updated version.
With these patches we now server readdir() out of cache for shroot
which eliminates at least three roundtrips:
* the initial Create+QueryDirectory
* the Query_Directory that fails with no more files
* the Close

Since we only cache name, inode and type we will still have the 
Create/GetInfo/Close calls for every direcotry member.
To solve that and eliminate those calls I chatted with Steve
and we could cache all information about those child objects for ~1 second.

That would not plug into cifs_readdir() but in parts different parts of
the cifs.ko code so it should into its own patch for
"fetch stat() data for objects from the directory cache, if available".
That would be a different patch series.


V3:
* always take out shroot on the master tcon
* fix bug where we would still do one FindFirst even if we had everything cached

V2: addressing Aureliens comments
* Fix comment style
* Describe what ctx->pos == 2 means
* use is_smb1_server()


See initial implementation of a mechanism to cache the directory entries for
a shared cache handle (shroot).
We cache all the entries during the initial readdir() scan, using the context
from the vfs layer as the key to handle if there are multiple concurrent readir() scans
of the same directory.
Then if/when we have successfully cached the entire direcotry we will server any
subsequent readdir() from out of cache, avoinding making any query direcotry calls to the server.

As with all of shroot, the cache is kept until the direcotry lease is broken.


The first two patches are small and just a preparation for the third patch. They go as separate
patches to make review easier.
The third patch adds the actual meat of the dirent caching .


For now this might not be too exciting because the only cache the root handle.
I hope in the future we will expand the directory caching to handle any/many direcotries.


             reply	other threads:[~2020-10-05  2:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05  2:37 Ronnie Sahlberg [this message]
2020-10-05  2:37 ` [PATCH 1/3] cifs: return cached_fid from open_shroot Ronnie Sahlberg
2020-10-05  2:37 ` [PATCH 2/3] cifs: compute full_path already in cifs_readdir() Ronnie Sahlberg
2020-10-05  2:37 ` [PATCH 3/3] cifs: cache the directory content for shroot Ronnie Sahlberg

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=20201005023754.13604-1-lsahlber@redhat.com \
    --to=lsahlber@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=smfrench@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.