xfsqa: Fix various test-suite related failures

These are all code changes to the test suite to fix problems with the execution of tests on a bleeding edge system.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

It does not contain the output from the recently added test, so fails when the test actually succeeds.

---
 214.out |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

index b6344c2..9a7a3cf 100644
@@ -39,3 +39,7 @@ XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 *
 read 90112/90112 bytes at offset 0
 XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+=== delalloc write 16k; fallocate same range ===
+wrote 16384/16384 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+

1.6.5

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Looks good,

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Using signal() to set up signal handlers doesn't always do what you want. A recent upgrade made test 208 fail because wait() was not getting interrupted by a SIGALRM. Tracing showed that signal() was being converted to a sigaction(SA_RESTART) handler, which allows syscalls that return ERESTARTSYS to immediately restart without returning EINTR to the calling process. The kernel code returns ERESTARTSYS to signal interruptions while in wait().

Replace the use of signal with sigaction() to ensure that the SA_RESTART flag is not set and the EINTR is delivered to the process sitting in wait(). This makes test 208 terminate at 200s again.

---
 src/aio-dio-regress/aio-dio-invalidate-failure.c |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

index be01a3a..24f3e3c 100644
@@ -21,6 +21,7 @@
 #include <unistd.h>
 #include <stdio.h>
 #include <stdlib.h>
+#include <signal.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>

@@ -117,6 +118,7 @@ int main(int argc, char **argv)
 	int fd;
 	int fd2;
 	int status;
+	struct sigaction sa;
 
 	if (argc != 2)
 		fail("only arg should be file name");

@@ -150,7 +152,12 @@ int main(int argc, char **argv)
 		exit(0);
 	}
 
-	signal(SIGALRM, alarm_handler);
+	memset(&sa, 0, sizeof(sa));
+	sa.sa_handler = alarm_handler;
+	sigemptyset(&sa.sa_mask);
+	if (sigaction(SIGALRM, &sa, NULL) == -1)
+		fail("sigaction: %d\n", errno);
+
 	alarm(SECONDS);
 
 	pid = wait(&status);

1.6.5

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Yeah, signal is deprecated in favour of sigaction for a reason..

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Test 017 is consistently failing now because the xfs_check uses buffered IO to read the block device and 017 runs xfs_check ona remount,ro filesystem. Hence the block device cache is never invalidated (the unmount path does this) and so xfs_check can see stale blocks from previous invocations instead of what is really on disk at the time it is run.

Manually trash the page cache before running xfs_check to ensure that the blockdev cache is clean and we don't get false errors from stale blocks.

---
 common.rc |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

index 6424871..896e38d 100644
@@ -318,6 +318,7 @@ _scratch_xfs_check()
     SCRATCH_OPTIONS=""
     [ "$USE_EXTERNAL" = yes -a ! -z "$SCRATCH_LOGDEV" ] && \
         SCRATCH_OPTIONS="-l $SCRATCH_LOGDEV"
+    [ "$HOSTOS" = "Linux" ] && echo 1 > /proc/sys/vm/drop_caches
     $XFS_CHECK_PROG $SCRATCH_OPTIONS $* $SCRATCH_DEV
 }
 

@@ -931,6 +932,7 @@ _check_xfs_filesystem()
         ok=0
     fi
 
+    [ "$HOSTOS" = "Linux" ] && echo 1 > /proc/sys/vm/drop_caches
     $XFS_CHECK_PROG $testoption $extra_log_options $device 2>&1 |\
 	 _fix_malloc >$tmp.fs_check
     if [ -s $tmp.fs_check ]

1.6.5

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

I don't think this is correct. We need to provide this synchronization from kernel land. IIRC Al even has a patch towards this in his tree, can't point you to it to try it because his tree on kernel.org seems messed up right now.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs