All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: fio@vger.kernel.org
Cc: andrey.o.kudryavtsev@intel.com, Luis Chamberlain <mcgrof@kernel.org>
Subject: [PATCH 1/2] client: respect terse output on client <--> backend relationship
Date: Tue, 21 Aug 2018 12:08:23 -0700	[thread overview]
Message-ID: <20180821190824.29928-2-mcgrof@kernel.org> (raw)
In-Reply-To: <20180821190824.29928-1-mcgrof@kernel.org>

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.

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
 client.c | 16 +++++++++++++---
 stat.c   |  2 ++
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/client.c b/client.c
index e2525c81..bc0275b6 100644
--- a/client.c
+++ b/client.c
@@ -1058,6 +1058,9 @@ static void handle_ts(struct fio_client *client, struct fio_net_cmd *cmd)
 	struct flist_head *opt_list = NULL;
 	struct json_object *tsobj;
 
+	if (output_format & FIO_OUTPUT_TERSE)
+		return;
+
 	if (client->opt_lists && p->ts.thread_number <= client->jobs)
 		opt_list = &client->opt_lists[p->ts.thread_number - 1];
 
@@ -1094,6 +1097,9 @@ static void handle_gs(struct fio_client *client, struct fio_net_cmd *cmd)
 {
 	struct group_run_stats *gs = (struct group_run_stats *) cmd->payload;
 
+	if (output_format & FIO_OUTPUT_TERSE)
+		return;
+
 	if (output_format & FIO_OUTPUT_NORMAL)
 		show_group_stats(gs, NULL);
 }
@@ -1140,7 +1146,7 @@ static void handle_text(struct fio_client *client, struct fio_net_cmd *cmd)
 
 	name = client->name ? client->name : client->hostname;
 
-	if (!client->skip_newline)
+	if (!client->skip_newline && !(output_format & FIO_OUTPUT_TERSE))
 		fprintf(f_out, "<%s> ", name);
 	ret = fwrite(buf, pdu->buf_len, 1, f_out);
 	fflush(f_out);
@@ -1184,6 +1190,9 @@ static void handle_du(struct fio_client *client, struct fio_net_cmd *cmd)
 {
 	struct cmd_du_pdu *du = (struct cmd_du_pdu *) cmd->payload;
 
+	if (output_format & FIO_OUTPUT_TERSE)
+		return;
+
 	if (!client->disk_stats_shown) {
 		client->disk_stats_shown = true;
 		log_info("\nDisk stats (read/write):\n");
@@ -1195,8 +1204,6 @@ static void handle_du(struct fio_client *client, struct fio_net_cmd *cmd)
 		duobj = json_array_last_value_object(du_array);
 		json_object_add_client_info(duobj, client);
 	}
-	if (output_format & FIO_OUTPUT_TERSE)
-		print_disk_util(&du->dus, &du->agg, 1, NULL);
 	if (output_format & FIO_OUTPUT_NORMAL)
 		print_disk_util(&du->dus, &du->agg, 0, NULL);
 }
@@ -1456,6 +1463,9 @@ static void handle_probe(struct fio_client *client, struct fio_net_cmd *cmd)
 	const char *os, *arch;
 	char bit[16];
 
+	if (output_format & FIO_OUTPUT_TERSE)
+		return;
+
 	os = fio_get_os_string(probe->os);
 	if (!os)
 		os = "unknown";
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]);
 		} else {
 			if (output_format & FIO_OUTPUT_TERSE)
 				show_thread_status_terse(ts, rs, &output[__FIO_OUTPUT_TERSE]);
-- 
2.18.0



  reply	other threads:[~2018-08-21 22:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-21 19:08 [PATCH 0/2] fio: few enhancements Luis Chamberlain
2018-08-21 19:08 ` Luis Chamberlain [this message]
2018-08-31  5:43   ` [PATCH 1/2] client: respect terse output on client <--> backend relationship Sitsofe Wheeler
2018-08-21 19:08 ` [PATCH 2/2] init: add semantics for all types of backends running Luis Chamberlain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180821190824.29928-2-mcgrof@kernel.org \
    --to=mcgrof@kernel.org \
    --cc=andrey.o.kudryavtsev@intel.com \
    --cc=fio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.