On Fri, Mar 11, 2022 at 02:41:23PM +0530, Nitin Jadhav wrote:
>
> Ok. I agree that it is difficult to interpret it correctly. So even if
> say that a new checkpoint has been explicitly requested, the user may
> not understand that it affects current checkpoint behaviour unless the
> user knows the internals of the checkpoint. How about naming the field
> to 'throttled' (Yes/ No) since our objective is to show that the
> current checkpoint is throttled or not.
-1
That "throttled" flag should be the same as having or not a "force" in the
flags. We should be consistent and report information the same way, so either
a lot of flags (is_throttled, is_force...) or as now a single field containing
the set flags, so the current approach seems better. Also, it wouldn't be much
better to show the checkpoint as not having the force flags and still not being
throttled.
Why not just reporting (ckpt_flags & (CHECKPOINT_REQUESTED |
CHECKPOINT_IMMEDIATE)) in the path(s) that can update the new flags for the
view?
CHECKPOINT_REQUESTED will always be set by RequestCheckpoint(), and can be used
to detect that someone wants a new checkpoint afterwards, whatever it's and
whether or not the current checkpoint to be finished quickly. For this flag I
think it's better to not report it in the view flags but with a new field, as
discussed before, as it's really what it means.
CHECKPOINT_IMMEDIATE is the only new flag that can be used in an already in
progress checkpoint, so it can be simply added to the view flags.
