From: Patrick Goetz <pgoetz@math.utexas.edu>
To: Anna Schumaker <schumaker.anna@gmail.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Rick Macklem <rmacklem@uoguelph.ca>
Subject: Re: cto changes for v4 atomic open
Date: Fri, 6 Aug 2021 13:58:24 -0500 [thread overview]
Message-ID: <5882ecc4-c582-e7a4-4638-3c8bbb21c597@math.utexas.edu> (raw)
In-Reply-To: <CAFX2JfkhqJK6MRFDCzE4VryBJvk1ttYQvrASugncY-_wcEb=+Q@mail.gmail.com>
Hi -
I'm having trouble reconciling this comment:
On 8/4/21 1:24 PM, Anna Schumaker wrote:
>>
>> So, I have a naive question. When a client is writing to cache, why
>> wouldn't it be possible to send an alert to the server indicating that
>> the file is being changed. The server would keep track of such files
>> (client cached, updated) and act accordingly; i.e. sending a request to
>> the client to flush the cache for that file if another client is asking
>> to open the file? The process could be bookended by the client alerting
>> the server when the cached version has been fully synchronized with the
>> copy on the server so that the server wouldn't serve that file until the
>> synchronization is complete. The only problem I can see with this is the
>> client crashing or disconnecting before the file is fully written to the
>> server, but then some timeout condition could be set.
>
> We already have this! What you're describing is almost exactly how
> delegations work :)
>
with this one:
On 8/4/21 10:42 AM, Rick Macklem wrote:
>
> There is no notification mechanism defined for any version of NFS.
How can you do delegations if there's no notification system?
next prev parent reply other threads:[~2021-08-06 18:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 13:25 cto changes for v4 atomic open Benjamin Coddington
2021-07-30 14:48 ` Trond Myklebust
2021-07-30 15:14 ` Benjamin Coddington
2021-08-03 20:30 ` J. Bruce Fields
2021-08-03 21:07 ` Trond Myklebust
2021-08-03 21:36 ` bfields
2021-08-03 21:43 ` Trond Myklebust
2021-08-03 23:47 ` NeilBrown
2021-08-04 0:00 ` Trond Myklebust
2021-08-04 0:04 ` Trond Myklebust
2021-08-04 0:57 ` NeilBrown
2021-08-04 1:03 ` Trond Myklebust
2021-08-04 1:16 ` bfields
2021-08-04 1:25 ` Trond Myklebust
2021-08-04 1:30 ` NeilBrown
2021-08-04 1:38 ` Trond Myklebust
2021-08-09 4:20 ` NeilBrown
2021-08-09 14:22 ` Trond Myklebust
2021-08-09 14:43 ` Chuck Lever III
2021-08-04 1:43 ` Matt Benjamin
2021-08-04 1:51 ` Matt Benjamin
2021-08-04 2:10 ` Trond Myklebust
2021-08-04 14:49 ` Patrick Goetz
2021-08-04 15:42 ` Rick Macklem
2021-08-04 18:24 ` Anna Schumaker
2021-08-06 18:58 ` Patrick Goetz [this message]
2021-08-07 1:03 ` Rick Macklem
2021-08-04 18:33 ` Matt Benjamin
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=5882ecc4-c582-e7a4-4638-3c8bbb21c597@math.utexas.edu \
--to=pgoetz@math.utexas.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=rmacklem@uoguelph.ca \
--cc=schumaker.anna@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.