On Mon, May 30, 2022 at 10:44:52AM +1000, Dave Chinner wrote:
> 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.
Wow, that's it! You reveal the root cause of this issue :)
Thanks,
Zorro
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>
