Patrick Goetz wrote:
>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?
When you asked the question, there was no mention of delegations
and only a discussion of caching. Delegations deal with Opens and,
yes, can be used to maintain consistent data caches when they happen
to be issued to client(s).
For write delegations, it works like this:
- When a client does an Open for writing, the server might choose to
issue a write delegation to the client. (It is not required to do so and
there is nothing a client can do to ensure that the server chooses to
do so. The only rule is "no callback path-->no delegation can be issued".
- If the client happens to get a write delegation, then it can assume no
other client is reading or writing the file (unless the client fails to maintain
its lease, due to network partitioning or ???).
--> Therefore it can safely cache the file's data, unless the server allow
I/O to be done using special stateids. More on this later.
- If the server received an Open request from another client for the file,
then it does a CB_RECALL callback to tell the client that it must return
the delegation.
--> The client can no longer safely cache file data once the delegation
is returned, since the server will then allow the other client to Open
the file.
--> If the client fails to return the delegation for a lease duration, then the
server can throw the delegation away.
--> If the client does not maintain its lease and maintain its callback
path, the client cannot safely cache data based on the delegation,
since it might have been discarded by the server.
In general, a delegation allows the client to do additional Opens on a file
without doing an Open on the server (called level 2 OpLocks in Windows world,
I think?).
The effect of consistent data caches depends upon two things, which a server
might or might not do:
1 - Issue delegations.
2 - Not allow I/O using special stateids. If any client can do I/O using special
stateids, then the I/O can be done without having an Open or delegation for
the file on the server.
In general, a client cannot easily tell if these are the case. I suppose it could try
an I/O with a special stateid, but that really only confirms that this particular client
cannot do I/O with special stateids, not that no client can do so.
A client can see that it acquired a delegation, but can do nothing if it did not get one.
--> Is a client going to not cache data for every file, where the server chooses not to
issue a delegation.
Back to your question. You can consider the CB_RECALL callback a notification, but it
is in a sense a notification to the client that the delegation must be returned, not that file data
has changed on the server. In other words, a CB_RECALL is done when another client
requests a conflicting Open, not when data on the server has been changed.
--> This has a similar effect to a notification that the data will/has changed, only if
the server requires all I/O present an Open/Lock/Delegation stateid.
--> No special stateids allowed and no NFSv3 I/O allowed by the server.
(The term notification is used in the NFSv4 RFCs for other things, but no CB_RECALL callbacks.)
rick
