[LU-15178] clean up/clarify use of CEF_SPECULATIVE/LDLM_FL_SPECULATIVE

• Type: Improvement
• Resolution: Unresolved
• Priority: Minor
• Assignee: Patrick Farrell (Inactive)
• Reporter: Patrick Farrell (Inactive)

Description

There were some poor choices made (by me) when the lockahead code was originally finalized.  The concept of a "speculative" lock, a lock requested before it's used (and which may never be used), is a mix of two things: asynchronous on the client, and nonblocking (in terms of not cancelling or waiting for other locks) on the server.

But the async behavior is a client only concept, so LDLM_FL_SPECULATIVE only actually enforces non-blocking behavior, and has nothing to do with async.  (The existing LDLM_FL_BLOCK_NOWAIT is also used for O_NONBLOCK in a way which means it could not be reused for this.)

Async lock requests must be non-blocking, but non-blocking requests are not fundamentally speculative.

Separating the concept of async requests from the concept of a non-blocking request lets us make non-blocking requests for readahead, where the request is best described as 'optional' - The lock will always be used if it is granted, but it's OK if it's not granted.

This means creating separate CEF_ASYNC and CEF_NOWAIT flags on the client.  CEF_ASYNC does require CEF_NOWAIT, but CEF_NOWAIT does not require CEF_ASYNC.  (We'll enforce this with an assert.)

It's also a good idea to rename the existing LDLM_FL_SPECULATIVE lock flag to LDLM_FL_NOWAIT - the behavior and the bit # will remain unchanged, so we can rename it without causing interop issues with older clients.  This will be carefully commented in the code.

To summarize, there are three variables which describe a lock request.
Sync vs Async: Is the requesting thread going to wait for the response from the server?

Blocking vs non-blocking (wait vs nowait): Will the lock request cancel existing locks, or will it fail if it finds a conflicting lock?  Note that async requires non-blocking.

Expansion vs No-expansion: No-expand is a property of lockahead locks, where they have manually specified extent ranges and the server does not expand them.  Normal locks are expanded.

Today, we allow the following:

Sync/Async	Blocking/Non-Blocking	Expansion/No Expansion	Notes
Sync	Blocking	Expansion	OK
Sync	Blocking	No Expansion	OK
Sync	Non-Blocking	Expansion	Not allowed today because Async + Non-blocking behavior combined. New patch allows this by separating behavior.
Sync	Non-Blocking	No Expansion	Not allowed today because Async + Non-blocking behavior combined. New patch allows this by separating behavior.
Async	Blocking	Expansion	No async + blocking
Async	Blocking	No Expansion	No async + blocking
Async	Non-Blocking	Expansion	Not allowed, due to size issues explained in ofd_intent_cb. Can allow for read locks, will do so in new patch.
Async	Non-Blocking	No Expansion	OK (Standard lockahead)

A little complicated.

Patch forthcoming later.