All of lore.kernel.org
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
To: linux-nfs@vger.kernel.org
Subject: client caching and locks
Date: Mon, 8 Jun 2020 17:19:45 -0400	[thread overview]
Message-ID: <20200608211945.GB30639@fieldses.org> (raw)

What does the client do to its cache when it writes to a locked range?

The RFC:

	https://tools.ietf.org/html/rfc7530#section-10.3.2

seems to apply that you should get something like local-filesystem
semantics if you write-lock any range that you write to and read-lock
any range that you read from.

But I see a report that when applications write to non-overlapping
ranges (while taking locks over those ranges), they don't see each
other's updates.

I think for simultaneous non-overlapping writes to work that way, the
client would need to invalidate its cache on unlock (except for the
locked range).  But i can't tell what the client's designed to do.

--b.

             reply	other threads:[~2020-06-08 21:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 21:19 J. Bruce Fields [this message]
2020-06-18  9:54 ` client caching and locks inoguchi.yuki
2020-06-18 14:29   ` Trond Myklebust
2020-06-18 20:09     ` bfields
2020-06-22 13:52       ` bfields
2020-10-01 21:47         ` bfields
2020-10-01 22:26           ` Matt Benjamin
2020-10-06 17:26             ` bfields
2021-12-28  2:39               ` inoguchi.yuki
2021-12-28  5:11               ` NeilBrown
2022-01-03 16:20                 ` 'bfields@fieldses.org'
2022-01-04  9:24                   ` inoguchi.yuki
2022-01-04 12:36                     ` Trond Myklebust
2022-01-04 15:32                       ` bfields
2022-01-04 15:54                         ` Trond Myklebust
2022-01-05  9:31                           ` inoguchi.yuki
2022-01-05 22:03                             ` 'bfields@fieldses.org'
2022-01-06  7:23                               ` inoguchi.yuki
2022-01-06 14:16                                 ` 'bfields@fieldses.org'
2022-01-07  8:33                                   ` inoguchi.yuki
2022-01-09 22:16                                   ` NeilBrown
2022-01-09 22:38                                     ` 'bfields@fieldses.org'
2022-01-09 21:58                               ` NeilBrown
2022-01-09 22:41                                 ` 'bfields@fieldses.org'
2022-01-17  9:09                                 ` inoguchi.yuki
2022-01-17 22:27                                 ` NeilBrown
2022-02-02  4:09                                   ` inoguchi.yuki
2022-02-02  4:25                                     ` Trond Myklebust
2022-02-02  4:44                                   ` NeilBrown
2022-02-03  7:31                                     ` inoguchi.yuki
2022-02-07  4:16                                     ` NeilBrown

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=20200608211945.GB30639@fieldses.org \
    --to=bfields@fieldses.org \
    --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 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.