Re: [PATCH v2 2/2] wrapper: use trace2 counters to collect fsync stats

[Junio C Hamano <gitster@pobox.com>]

Beat Bolli <dev+git@drbeat.li> writes:

> As mentioned in the thread starting at [1], trace2 counters should be
> used to count events instead of ad-hoc static variables.
>
> Convert the two fsync static variables to trace2 counters, reducing the
> coupling between wrapper.c and the trace2 subsystem. Adjust t/t5351 to
> match the trace2 counter output format.
>
> The counters are not per-thread because the ones being replaced also
> were not.
>
> [1] https://lore.kernel.org/git/20230627195251.1973421-2-calvinwan@google.com/
>
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
> ---
> v2:
> - Adjust t/t5351
> - Update commit message

I also spotted this change since v1:

- Rename trace2 counters to use "-" (not "_") as inter-word separators.

Since I do not seem to be able to find any review comments regarding
the variable naming in the v1's thread, let's ask stakeholders.

Are folks involved in the trace2 subsystem (especially Jeff
Hostetler---already CC:ed---who presumably has the most stake in it)
OK with the naming convention of the multi-word variable?  This is
the first use of multi-word variable name in tr2_ctr, and thus will
establish whatever convention you guys want to use.  I do have a
slight preference of "writeout-only" over "writeout_only" but that
is purely from visual appearance.  If there is a desire to keep the
names literally reusable as identifiers in some languages used to
postprocess trace output, or something, that might weigh
differently.

>  t/t5351-unpack-large-objects.sh |  6 +++---
>  trace2.c                        |  1 -
>  trace2.h                        |  4 ++++
>  trace2/tr2_ctr.c                | 10 ++++++++++
>  wrapper.c                       | 19 ++-----------------
>  wrapper.h                       |  5 -----
>  6 files changed, 19 insertions(+), 26 deletions(-)

Very nice to see clean-up patch that reduces the amount of code.
Nicely done.

Thanks, will queue.  If folks do not find issues in a few days,
let's merge it to 'next'.