Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Tom Talpey <tom@talpey.com>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: Ronnie Sahlberg <lsahlber@redhat.com>,
	linux-cifs <linux-cifs@vger.kernel.org>,
	Steve French <smfrench@gmail.com>
Subject: Re: [PATCH 6/6] cifs: do not cache leased directories for longer than 30 seconds
Date: Thu, 25 Aug 2022 11:29:22 -0400	[thread overview]
Message-ID: <83e8820f-8ea4-5ca4-d902-109980254206@talpey.com> (raw)
In-Reply-To: <CAN05THQ9Dev9s44M_XfmxOr3HZxuC_L-FWC5pOa-qxnOeVfxDQ@mail.gmail.com>

On 8/25/2022 12:39 AM, ronnie sahlberg wrote:
> On Wed, 24 Aug 2022 at 23:58, Tom Talpey <tom@talpey.com> wrote:
>> Is it worth considering making HZ*30 into a tunable?
> 
> Maybe. I can add that when I re-spin this patch.
> Recinding leases is super hard to get right. Recind them too quickly
> and you miss out on potential performance.
> Recind them too late and you hurt performance, at least for other clients.
> 
> Right now the caching is binary. It is either enabled, or fully disabled.
> I would like to have timeouts like this to be auto-adjusted by the
> module itself, because setting it "correctly"
> or "optimally" will probably be super hard, to impossible, for the
> average sysadmin.
> Heck, I don't think I could even set a parameter like this correctly.
> And that is even not taking into account that workloads change
> dynamically over time so any fixed value will only
> be "correct" for some/part of the time anyway. Sometimes these changes
> occur over just a few minutes/hours so a fixed value is impossible to
> come up with.
> 
> I think it would be possible to have this to be automatically and
> dynamically adjusted.
> I want to measure things like "how often do we re-open a directory
> while holding a lease",   "how often is the lease broken by the
> server"
> and try to keep the first as high as possible while also have the
> second as low, or zero.
> And have this adjust automatically at runtime.

Unfortunately I think the problem is that the lease behavior is
dependent on the workload, and whether the app is sharing files.
If the lease is never recalled, obviously the caching can be
"forever". But apps banging heads over a set of shared files in
a shared directory will be nearly pointless. I'm not sure how
you can sanely automate that detection.

However, it seems to me that 30 seconds is pretty arbitrary.
It might help speed up a "tar x" or "tar c" but is it broadly
worthwhile? Would 5 seconds do the same? Dunno.

Tom.

      reply	other threads:[~2022-08-25 15:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24  0:27 Cifs: caching of arbitrary directories and attributes Ronnie Sahlberg
2022-08-24  0:27 ` [PATCH 1/6] cifs: Make tcon contain a wrapper structure cached_fids instead of cached_fid Ronnie Sahlberg
2022-08-24  0:27 ` [PATCH 2/6] cifs: cifs: handlecache, only track the dentry for the root handle Ronnie Sahlberg
2022-08-24 13:26   ` Tom Talpey
2022-08-25  4:22     ` ronnie sahlberg
2022-08-24  0:27 ` [PATCH 3/6] cifs: store a pointer to a fid in the cfid structure instead of the struct Ronnie Sahlberg
2022-08-24  0:27 ` [PATCH 4/6] cifs: start caching all directories we open and get a lease for Ronnie Sahlberg
2022-08-24 13:36   ` Tom Talpey
2022-08-25  4:22     ` ronnie sahlberg
2022-08-24  0:27 ` [PATCH 5/6] cifs: find and use the dentry for cached non-root directories also Ronnie Sahlberg
2022-08-24 13:43   ` Tom Talpey
2022-08-25  4:21     ` ronnie sahlberg
2022-08-24  0:27 ` [PATCH 6/6] cifs: do not cache leased directories for longer than 30 seconds Ronnie Sahlberg
2022-08-24 13:48   ` Tom Talpey
2022-08-25  4:39     ` ronnie sahlberg
2022-08-25 15:29       ` Tom Talpey [this message]

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=83e8820f-8ea4-5ca4-d902-109980254206@talpey.com \
    --to=tom@talpey.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=lsahlber@redhat.com \
    --cc=ronniesahlberg@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox