Nice, fio left me a note - and it breaks json parsing

[RJVB]

Hi,

fio/backend.c

Line 1931 in 1a04e57

log_info("note: both iodepth >= 1 and synchronous I/O engine "

Is there a reason why this note about capping the number of queues is prepended to and outside of the json output? Qt's QJsonDocument parser stumbles over that so I have to do some addditional manual parsing.

Wouldn't it be possible to integrate the note into the json structure instead?

[vincentkfu]

This is a longstanding issue.

The main impediment is that log_info() is used for these messages as well as for the JSON output, so I don't see an easy fix.

See this recent issue #2048 and similar ones linked within.

[RJVB]

On Friday February 20 2026 16:03:57 Vincent Kang Fu wrote: This is a longstanding issue.

I searched ... but only in the discussions section :-/

The main impediment is that `log_info()` is used for these messages as well as for the JSON output, so I don't see an easy fix.

Does it generate the json itself, or does it otherwise know that json output has been requested? That seems like a minimum requirement here, to start addressing the issue. One easy fix would be to send the notes to stderr (but without exiting with an error code if that doesn't already happen). If that breaks any code invoking fio it'll probably be easier to work around than pre-processing the json output; I see that my case was still simple! A bit more involved: if it is known that json output should be generated, ensure that this output can be done in the appropriate fashion (`"note" : "message",`) and that the json document is opened first.

[sitsofe]

@RJVB:

Does it log_info() generate the json itself, or does it otherwise know that json output has been requested? That

At the time of writing, no it doesn't generate JSON nor is it aware that JSON output has been requested.

One easy fix would be to send the notes to stderr

I point you towards the long discussion in #731 but explicitly the part starting at #731 (comment) . I (personally) think the idea is good but someone would "just" have to sit down and create the suitably good patches to make it happen. For this work to be complete said person would also have to find and convert all the bare printfs (or their equivalent) sites that display warnings/errors to log_info()/log_error().

A bit more involved: if it is known that json output should be generated, ensure that this output can be done in the appropriate fashion ("note" : "message",) and that the json document is opened first.

Another good idea (if I do say so myself) - I point you towards the comment #731 (comment) and the comments below. Again someone would "just" need to sit down and create the patches.

[RJVB]

On Saturday February 21 2026 03:18:25 Sitsofe Wheeler wrote: For this work to be complete said person would also have to find and convert all the bare `printf`s (or their equivalent) sites that display warnings/errors and convert them to `log_info()`/`log_error()`.

That sounds like the more involved part ... esp. if the equivalents include "alienOS"-specific calls. I'll have a look at the discussions at an appropriate moment. But so the problem goes beyond just the generation of "note:" output? Integrating those into the json output should be less work as the sites should be easier to find (and probably fewer), and opening the json container should be as simple as making sure the fio version and other header info is output before any other output can be generated. Which reminds me: that is the case for the regular output format, which kind of begs the question why the order is different for json output?

Again _someone_ would "just" need to sit down and create the patches.

If you ask me, someone would also have to sit down and write a CMake configure script (or any equivalent) if not only because that makes it easier to import the entire project into an IDE with "intellisense" features.

[sitsofe]

But so the problem goes beyond just the generation of "note:" output?

Adding an extra key to the existing JSON output doesn't seem straightforward. Basically there's no pre-existing thread-safe function to build up a variable length structure that would be set at any point and only consumed (and presumably freed) when the JSON output is produced and that's before we worry about interaction with client/server mode. Please understand that fio didn't start its life targeting output for machines so that's why there's work involved to address that use case perfectly.

Integrating those into the json output should be less work as the sites should be easier to find (and probably fewer), and opening the json container should be as simple as making sure the fio version and other header info is output before any other output can be generated.

For now I disagree (see above) but that alone shouldn't stop someone from trying if they believe in this approach - if the work is elegant, robust, doesn't break anything and the reviewers are happy with it then why not?

Which reminds me: that is the case for the regular output format, which kind of begs the question why the order is different for json output?

Sorry you've lost me - I don't know anything about the order (as in what's shown first and what's shown second etc) of output being any different. Maybe it does change - I simply don't know. From what I can see in fio's source, warnings are often printed at the point the problem is detected and nothing says that won't overlap other output.

If you ask me, someone would also have to sit down and write a CMake configure script (or any equivalent) if not only because that makes it easier to import the entire project into an IDE with "intellisense" features.

Let's agree to disagree :-) If you have the right headers installed then an editor that can make use of a language server such as VSCode will have no trouble navigating/supporting completion of 99% of fio's source and a rebuild is a matter of running make. If you're old school you can use cscope to build a cross-reference that certain editors can use but this is far more basic than a language server.

Vincent is correct to say that error/warning messages breaking fio's JSON output is a known issue and you're not the first to encounter it. Don't feel it has to be you to slay this dragon but at this point it's kinder all round if we save deciding how easy fixing this is until after the patches that address it are in.

[RJVB]

On Saturday February 21 2026 08:33:59 Sitsofe Wheeler wrote: >Adding an extra key to the existing JSON output doesn't seem straightforward. Basically there's no pre-existing thread-safe function to build up a variable length structure that would be set at any point and only consumed (and presumably freed) when the JSON output is produced

Ahhh, the JSON is build up internally and not output on the fly. Yes, that doesn't make things easier, and would explain why the "note:" statements appear ahead of the JSON... My experience with JSON is strictly in treating it as a key-value dictionary where one doesn't have to care about keys on doesn't (want to) know about - as long as they don't interfere with the structure of course.

Vincent is correct to say that error/warning messages breaking fio's JSON output is a known issue and you're not the first to encounter it. Don't feel it has to be you to slay this dragon but at this point it's kinder all round if we save deciding how easy fixing this is until after the patches that address it are in.

So either way, a list will have to be made of the locations that will need some kind of modification. How about not just labelling them in the code, but addressing them one by one with a temporary workaround that solves the problem by dumping the error or warning to stderr? Not ideal from a project management point of view, but at least people will be able to use the product as intended while the discussions about a true and proper fix continue to go back and forth behind their backs ;)

[sitsofe]

How about not just labelling them in the code, but addressing them one by one with a temporary workaround that solves the problem by dumping the error or warning to stderr?

I'll leave that to the project to decide. I think the main problem raised by this discussion is covered by #731 so I'm happy to duck out at this point.

[RJVB]

I'll leave that to the project to decide.

Evidently. Whenever that'll be...