On Tue, 21 Aug 2018 at 20:31, Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
>
> You end up with different results if you run this terse output
> on a local system which also runs its own backend Vs running a
> client to connect to a remote server which is running fio as a
> backend only. The reason is the client ops handle printing of
> threads / disk utils separately. The terse output created *by*
> the backend is the right and expected output, so just use that,
> and we can piggy back off of the fact that the server will send
> its own output via FIO_NET_CMD_TEXT.
>
> Another solution is to address getting the disk util data sent
> to be cached locally, and then upon handle_ts() print that, but that
> would require significant re-architecturing.
>
> Terse output is supposed to be just that, terse. This implies
> that it will not be clear from what backend data came from, but
> for this the best strategy is to *extend* the terse version with
> yet another field, the remote hostname/ip address.
>
[...]
> diff --git a/stat.c b/stat.c
> index 82e79dfc..edf9ecf6 100644
> --- a/stat.c
> +++ b/stat.c
> @@ -1922,6 +1922,8 @@ void __show_run_stats(void)
> if (is_backend) {
> fio_server_send_job_options(opt_lists[i], i);
> fio_server_send_ts(ts, rs);
> + if (output_format & FIO_OUTPUT_TERSE)
> + show_thread_status_terse(ts, rs, &output[__FIO_OUTPUT_TERSE]);
What stops the extra disk usage output being suppressed in the
sub-calls from show_thread_status_terse? Were all the early returns
just stop the client requesting things like disk stats periodically
and to just let the servers send it at the end?
--
Sitsofe | http://sucs.org/~sits/
