[LTP] [PATCH v2 04/15] lib/tst_test: Add .all_filesystems flag
Jan Stancek
jstancek@redhat.com
Wed Oct 11 12:38:34 CEST 2017
----- Original Message -----
> Hi!
> > Overall series looks good to me. My tests on RHEL 5.6/6.0/7.4 and 4.14-rc
> > kernels went all without issues. Couple notes below.
> >
> > 1) When this is merged, we should also add some notes to docs.
> > For example: timeout applies for one filesystem, not all
> > combined.
>
> Sure, there is no documentation for the .all_filesystems flag yet, I
> will add it for the next iteration.
>
> > 2)
> > <snip>
> >
> > > +static int run_tcases_per_fs(void)
> > > +{
> > > + int ret = 0;
> > > + unsigned int i;
> > > + const char *const *filesystems = tst_get_supported_fs_types();
> > > +
> > > + if (!filesystems[0])
> > > + tst_brk(TCONF, "There are no supported filesystems");
> > > +
> > > + for (i = 0; filesystems[i]; i++) {
> > > + tdev.fs_type = filesystems[i];
> > > +
> > > + prepare_device();
> > > +
> > > + ret = fork_testrun();
> > > +
> > > + if (mntpoint_mounted) {
> > > + tst_umount(tst_test->mntpoint);
> > > + mntpoint_mounted = 0;
> > > + }
> > > +
> > > + if (ret == TCONF) {
> > > + update_results(ret);
> > > + continue;
> > > + }
> > > +
> > > + if (ret == 0)
> > > + continue;
> > > +
> > > + do_exit(ret);
> > > + }
> >
> > I'm on the fence here, if we should stop immediately after we get
> > a TFAIL or TBROK. For example: Is a TFAIL on ext2 reason to stop
> > testing xfs?
>
> I would go for stopping the whole test on TBROK, since we use TBROK for
> things that failed but shouldn't and it always had 'stop the test now,
> something is horribly broken' semantic.
>
> We probably can handle TFAIL here and continue gracefully. But notice
> that the only way to get TFAIL in here is when the test calls
> tst_brk(TFAIL, ...), which is very uncommon but indeed possible. That is
> since the test process exit value is 0 unless we called tst_brk(). On
> the other hand the tst_brk() means stop the test _now_ (unless in
> cleanup) in the newlib so it's cleaner desing if we leave this as it is.
I see, I was wrongly assuming that plain TFAIL will be propagated in
return code too. That only happens in do_exit().
>
> > 3) fs_fill test is still quite verbose
> >
> > # ./fs_fill > log2 2>&1
> > # du -h log2
> > 688K log2
> >
> > # grep Got log2
> > fs_fill.c:96: PASS: Got 5713 ENOSPC
> > fs_fill.c:96: PASS: Got 9 ENOSPC
> > fs_fill.c:96: PASS: Got 1709 ENOSPC
> >
> > I'm running this on single CPU KVM guest, which is (presumably due to
> > caching
> > and host SSD) able to trigger ENOSPC many times in those 2 seconds.
> >
> > I expect baremetal systems with many CPUs producing lot of output as well,
> > because we start tst_fill_fs() in NR_CPU+2 threads.
>
> Okay. What about rewriting the main loop to sleep in short intervals and
> check the ENOSCP counter and exit if reasonably large number was found.
There might be systems, where I/O is very slow and waiting for 100
ENOSPC might take too long. So, I think it should be both enospc_cnt
and total time as well. Whatever comes first, we exit. That should
limit max test output to ~10kB.
Regards,
Jan
>
> Something as:
>
> while (enospc_cnt < 100)
> usleep(1000);
>
> That would also make the coverage more stable as well.
>
> --
> Cyril Hrubis
> chrubis@suse.cz
>
More information about the ltp
mailing list