fstests: few updates

Some systems are not allowing usernames prefixed with a number now. One can however use numbers as a postfix so use that.

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 README                |  2 +-
 tests/generic/381     | 16 ++++++++--------
 tests/generic/381.out |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

README +0 -0

index ed69332e774e..e05142be1a87 100644

Some systems are not allowing usernames prefixed with a number now. One can however use numbers as a postfix so use that.

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 README                |  2 +-
 tests/generic/381     | 16 ++++++++--------
 tests/generic/381.out |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

README +1 -1

index ed69332e774e..e05142be1a87 100644
@@ -20,7 +20,7 @@ _______________________
 - run make
 - run make install
 - create fsgqa test user ("sudo useradd fsgqa")
-- create 123456-fsgqa test user ("sudo useradd 123456-fsgqa")
+- create fsgqa-381 test user ("sudo useradd fsgqa-381")
 
 ______________________
 USING THE FSQA SUITE

tests/generic/381 +0 -0

index 006f0d879638..cdc29c2e029e 100755

Modern gdbm-devel packages bundle together gdbm.h and ndbm.h. The old m4 macro had detection support for some old gdbm libraries but not for new ones.

We fix compilation of src/dbtest.c by making the autoconf helper check for this new arrangement:

If both gdbm.h and gdbm.h are found define set both gdbm_ndbm_=true,

and have_db=true, and define HAVE_GDBM_H. The src/dbtest.c already had a HAVE_GDBM_H but there was never a respective autoconf settter for it. We can just re-use this and fix it for new arrangement.

Signed-off-by Luis R. Rodriguez <[email protected]>

Quoted 8 lines · Luis R. Rodriguez

Modern gdbm-devel packages bundle together gdbm.h and ndbm.h. The old m4 macro had detection support for some old gdbm libraries but not for new ones.

We fix compilation of src/dbtest.c by making the autoconf helper check for this new arrangement:

If both gdbm.h and gdbm.h are found define set both gdbm_ndbm_=true,

                     ^^^^^^ ndbm.h?

Quoted 4 lines

and have_db=true, and define HAVE_GDBM_H. The src/dbtest.c already had a HAVE_GDBM_H but there was never a respective autoconf settter for it. We can just re-use this and fix it for new arrangement.

Quoted 1 line

Signed-off-by Luis R. Rodriguez <[email protected]>

This looks fine to me.

The only system I have by hand that have both <gdbm.h> and <ndbm.h> but not any <gdbm/[gn]dbm.h> is openSUSE Tumbleweed.

Without this patch,
dbtest was not built on openSUSE, and was built successfully with this patch applied.

And dbtest is still built on RHEL6/7 and Fedora.

BTW, I'll queue patch 3 and this patch for next fstests release, while other patches seem not necessary,

I agreed with Dave that groups are not
for excluding tests, the required tools and environments should be detected by tests and _notrun if not met.

(The README change looks fine,
but it doesn't apply due to the "fsgqa-381" change, so I drop it too for now.)

Quoted 14 lines · Eryu Guan

Quoted 8 lines · Luis R. Rodriguez

Modern gdbm-devel packages bundle together gdbm.h and ndbm.h. The old m4 macro had detection support for some old gdbm libraries but not for new ones.

We fix compilation of src/dbtest.c by making the autoconf helper check for this new arrangement:

If both gdbm.h and gdbm.h are found define set both gdbm_ndbm_=true,

                     ^^^^^^ ndbm.h?

Quoted 4 lines

and have_db=true, and define HAVE_GDBM_H. The src/dbtest.c already had a HAVE_GDBM_H but there was never a respective autoconf settter for it. We can just re-use this and fix it for new arrangement.

Quoted 6 lines

Quoted 1 line

Signed-off-by Luis R. Rodriguez <[email protected]>

This looks fine to me.

The only system I have by hand that have both <gdbm.h> and <ndbm.h> but not any <gdbm/[gn]dbm.h> is openSUSE Tumbleweed.

Indeed, openSUSE and SLE releases.

Quoted 3 lines

Without this patch,
dbtest was not built on openSUSE, and was built successfully with this patch applied.

Yeap.

Quoted 1 line

And dbtest is still built on RHEL6/7 and Fedora.

Feel free to modify the commit log accordingly then. Curious, what packages does Fedora/ RHEL6/7 use for the requirement here?

We just have one:

$ rpm -ql gdbm-devel-1.12-1.282.x86_64
/usr/bin/gdbm_dump
/usr/bin/gdbm_load
/usr/bin/gdbmtool
/usr/include/dbm.h
/usr/include/gdbm.h
/usr/include/ndbm.h
/usr/lib64/libgdbm.a
/usr/lib64/libgdbm.so
/usr/lib64/libgdbm_compat.a

/usr/lib64/libgdbm_compat.so
/usr/lib64/libndbm.a
/usr/lib64/libndbm.so
/usr/share/info/gdbm.info.gz
/usr/share/man/man1/gdbm_dump.1.gz
/usr/share/man/man1/gdbm_load.1.gz
/usr/share/man/man1/gdbmtool.1.gz
/usr/share/man/man3/gdbm.3.gz

Quoted 3 lines

BTW, I'll queue patch 3 and this patch for next fstests release, while other patches seem not necessary,

I think patch 2 is fine too.

Quoted 3 lines

I agreed with Dave that groups are not
for excluding tests, the required tools and environments should be detected by tests and _notrun if not met.

Yeah makes sense now. I think we should also document when adding a group makes sense as well.

Quoted 3 lines

(The README change looks fine,
but it doesn't apply due to the "fsgqa-381" change, so I drop it too for now.)

Feel free to modify it, its not a big deal.

Quoted 8 lines · Luis R. Rodriguez

Modern gdbm-devel packages bundle together gdbm.h and ndbm.h. The old m4 macro had detection support for some old gdbm libraries but not for new ones.

We fix compilation of src/dbtest.c by making the autoconf helper check for this new arrangement:

If both gdbm.h and gdbm.h are found define set both gdbm_ndbm_=true,

                     ^^^^^^ ndbm.h?

Quoted 5 lines

and have_db=true, and define HAVE_GDBM_H. The src/dbtest.c already had a HAVE_GDBM_H but there was never a respective autoconf settter for it. We can just re-use this and fix it for new arrangement.

Signed-off-by Luis R. Rodriguez <[email protected]>

This looks fine to me.

The only system I have by hand that have both <gdbm.h> and <ndbm.h> but not any <gdbm/[gn]dbm.h> is openSUSE Tumbleweed. Without this patch, dbtest was not built on openSUSE, and was built successfully with this patch applied. And dbtest is still built on RHEL6/7 and Fedora.

BTW, I'll queue patch 3 and this patch for next fstests release, while other patches seem not necessary, I agreed with Dave that groups are not for excluding tests, the required tools and environments should be detected by tests and _notrun if not met. (The README change looks fine, but it doesn't apply due to the "fsgqa-381" change, so I drop it too for now.)

This should make it easy to run these separately or exclude them.

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 tests/xfs/group | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

tests/xfs/group +0 -0

index d23006041ea2..cce98847de53 100644

Quoted 1 line · Luis R. Rodriguez

This should make it easy to run these separately or exclude them.

These should notrun automatically if you don't have an external log device configured. Every test should either work with an external logdev or explicitly notrun them, so I'm not sure what you're trying to acheive here....

Quoted 11 lines

Signed-off-by Luis R. Rodriguez <[email protected]>

---
 tests/xfs/group | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

tests/xfs/group +0 -0

index d23006041ea2..cce98847de53 100644

tests/xfs/group line 45

Quoted 5 lines

tests/xfs/group +1 -1

@@ -42,7 +42,7 @@
 042 fsr ioctl auto
 043 dump ioctl tape
 044 other auto
-045 other auto quick
+045 other auto quick logdev

This change also looks wrong because:

xfs/044 [not run] This test requires a valid $SCRATCH_LOGDEV xfs/045 1s ... 1s

xfs/044 is the external logdev test, and xfs/045 is a duplicate uuid mount test that has nothign to do with external log devices.

And, FWIW, we already have a "log" group to indicate tests that exercise the log, and that mostly includes all the tests that use external logs. It would be better to tag all the tests that exercise the log with "log" rather than create some new group that doesn't really provide any added benefit....

Quoted 7 lines · Dave Chinner

Quoted 1 line · Luis R. Rodriguez

This should make it easy to run these separately or exclude them.

These should notrun automatically if you don't have an external log device configured. Every test should either work with an external logdev or explicitly notrun them, so I'm not sure what you're trying to acheive here....

The way I'm splitting up tests is one first run with a basic xfs section on a configuration file, with no external log, which pretty much runs all tests but excludes all which require external or funky configurations.

A secondary pass then goes through these extra groups and then runs tests only for the previously excluded groups but with their own respective section. So for instance in this case I have:

[xfs]
....
[logdev_xfs]
...

Automatic detection if the requirements are met is fine, but this doesn't let me easily use say:

./check -s logdev_xfs -g logdev

Quoted 5 lines

And, FWIW, we already have a "log" group to indicate tests that exercise the log, and that mostly includes all the tests that use external logs. It would be better to tag all the tests that exercise the log with "log" rather than create some new group that doesn't really provide any added benefit....

So for my case would one better goal be to just run check without the external one and one with the external log?

You can't just run an internal log test then add couple of extra external log tests and say "external logs work fine".

Quoted 4 lines

Automatic detection if the requirements are met is fine, but this doesn't let me easily use say:

./check -s logdev_xfs -g logdev

You can do that if we ignore the fact that a large number of tests need to be run on both internal and external log devices to cover the differences in behaviour between them.

Quoted 8 lines

Quoted 5 lines

And, FWIW, we already have a "log" group to indicate tests that exercise the log, and that mostly includes all the tests that use external logs. It would be better to tag all the tests that exercise the log with "log" rather than create some new group that doesn't really provide any added benefit....

So for my case would one better goal be to just run check without the external one and one with the external log?

See above. Your test coverage assumptions are wrong, so what you are trying to do really doesn't tell you whether external logs work correctly or not. It's worse that not testing external logs at all, because it gives the false impression that they have been exhaustively tested and work just fine when that really isn't the case.

This lets us skip these tests on newer systems.

XFS error injection requires CONFIG_XFS_DEBUG and not all kernels have this enabled.