Re: [PATCH 3/5] generic/591: remove redundant output from golden image

[Dave Chinner <david@fromorbit.com>]

On Sun, May 29, 2022 at 06:55:03PM +0800, Zorro Lang wrote:
> In generic/591.out expects below output:
>   concurrent reader with O_DIRECT
>   concurrent reader with O_DIRECT     <=== ???
>   concurrent reader without O_DIRECT
>   concurrent reader without O_DIRECT  <=== ???
>   sequential reader with O_DIRECT
>   sequential reader without O_DIRECT
> 
> The lines marked "???" are unbelievable, due to the src/splice-test.c
> only calls printf to output that message once in main function. So
> Why splice-test prints that message twice sometimes? It seems related
> with the "-r" option, due to the test lines without "-r" option only
> print one line each time running.
>
> A stanger thing is this "double output" issue only can be triggered by
> running g/591, can't reproduce it by running splice-test manually.

Huh. I wonder....

> diff --git a/src/splice-test.c b/src/splice-test.c
> index 2f1ba2ba..e6ae6fca 100644
> --- a/src/splice-test.c
> +++ b/src/splice-test.c
> @@ -143,6 +143,7 @@ int main(int argc, char *argv[])
>  	printf("%s reader %s O_DIRECT\n",
>  		   do_splice == do_splice1 ? "sequential" : "concurrent",
>  		   (open_flags & O_DIRECT) ? "with" : "without");
> +	fflush(stdout);

Yeah, ok, stdout output is usually line buffered.  That printf()
statement has a "\n" on the end of it, so it should be flushing
immediately, and that's what you are seeing when it is run from the
command line.

Hmmmm. I wonder if the redirect to an output file (or pipe) is
changing the buffering mode because stdout no longer points to a
tty?

# src/xfstests-dev/src/splice-test -r /mnt/test/a
concurrent reader with O_DIRECT
# src/xfstests-dev/src/splice-test -r /mnt/test/a | less
concurrent reader with O_DIRECT
concurrent reader with O_DIRECT
#

Yup.

# man setbuf
....
	Normally all files are block buffered.  If a stream refers
	to a terminal (as stdout normally does), it is line
	buffered.   The standard  error  stream stderr is always
	unbuffered by default.

Yeah, so the stdout redirection that fstests does is exactly what is
changing the behaviour.

Ok, so the correct way to fix this is to add:

	setlinebuf(stdout);

before any printf() output to ensure that it is correctly line
buffered no matter what the output redirection does with stdout.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com