[Cluster-devel] [GFS2 PATCH 3/6] GFS2: Refactor function fast_to_acquire

[Bob Peterson <rpeterso@redhat.com>]

Hi,

----- Original Message -----
| Hi,
| 
| 
| On 10/01/18 20:42, Bob Peterson wrote:
| > Function fast_to_acquire determines if a rgrp ought to be fast to
| > acquire, but the logic was cryptic. This patch makes the logic more
| > straightforward:
| >
| > 1. If the rgrp is one of our "preferred" rgrps, consider it fast
| >     to acquire. This is how each node tries to confine its allocations
| >     to a set of rgrps unique from the other nodes, to reduce contention.
| > 2. If the rgrp glock is unlocked, consider it slow, because it will
| >     take some time to lock it, either for the DLM or for the glock
| >     state machine.
| > 3. If there are glock holders, consider it slow because we'd have to
| >     wait for another process to dequeue before we get our turn.
| > 4. If the glock is being demoted, consider it slow.
| >
| > Signed-off-by: Bob Peterson <rpeterso@redhat.com>
| This appears to mean that for preferred rgrps we will no longer take
| into account any of the other conditions. I'm not sure that is right,
| since we want to avoid rgrps that are in use by other nodes, or are
| being demoted, even if they are preferred. The location of the DLM lock
| master is not really that critical, the slow thing is the I/O that is
| done under the glocks,
| 
| Steve.

My logic in doing this was that I didn't want any one node to become a
resource hog and render the "preferred rgrp" concept useless because over
time it had slowly assumed control over more and more rgrp glocks.

I envisioned cases in which a gfs2 fs, after having been mounted for
several weeks, might no longer give out block reservations fairly between
nodes: a persistent writer might migrate most (or all) of the rgrp
glocks to itself to the detriment of the others, and being "preferred"
might become a meaningless afterthought.

Still, for some use cases you might have a "work horse" node that does
the majority of writing, and other nodes that are more consumers,
and in that case, maybe it does make more sense to check "preferred" last.

Thoughts?

Regards,

Bob Peterson
Red Hat File Systems