* [PATCH 1/3] xfsqa: update 214 golden output
2010-01-19 9:03 [PATCH 0/3] xfsqa: Fix various test-suite related failures Dave Chinner
@ 2010-01-19 9:03 ` Dave Chinner
2010-01-19 9:17 ` Christoph Hellwig
2010-01-19 9:03 ` [PATCH 2/3] xfsqa: Fix signal usage in aio-dio test code Dave Chinner
2010-01-19 9:03 ` [PATCH 3/3] xfsqa: xfs_check can see stale cached blocks Dave Chinner
2 siblings, 1 reply; 7+ messages in thread
From: Dave Chinner @ 2010-01-19 9:03 UTC (permalink / raw)
To: xfs
It does not contain the output from the recently added test,
so fails when the test actually succeeds.
Signed-off-by: Dave Chinner <david@fromorbit.com>
---
214.out | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/214.out b/214.out
index b6344c2..9a7a3cf 100644
--- a/214.out
+++ b/214.out
@@ -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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/3] xfsqa: Fix signal usage in aio-dio test code
2010-01-19 9:03 [PATCH 0/3] xfsqa: Fix various test-suite related failures Dave Chinner
2010-01-19 9:03 ` [PATCH 1/3] xfsqa: update 214 golden output Dave Chinner
@ 2010-01-19 9:03 ` Dave Chinner
2010-01-19 9:18 ` Christoph Hellwig
2010-01-19 9:03 ` [PATCH 3/3] xfsqa: xfs_check can see stale cached blocks Dave Chinner
2 siblings, 1 reply; 7+ messages in thread
From: Dave Chinner @ 2010-01-19 9:03 UTC (permalink / raw)
To: 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.
Signed-off-by: Dave Chinner <david@fromorbit.com>
---
src/aio-dio-regress/aio-dio-invalidate-failure.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/aio-dio-regress/aio-dio-invalidate-failure.c b/src/aio-dio-regress/aio-dio-invalidate-failure.c
index be01a3a..24f3e3c 100644
--- a/src/aio-dio-regress/aio-dio-invalidate-failure.c
+++ b/src/aio-dio-regress/aio-dio-invalidate-failure.c
@@ -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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 2/3] xfsqa: Fix signal usage in aio-dio test code
2010-01-19 9:03 ` [PATCH 2/3] xfsqa: Fix signal usage in aio-dio test code Dave Chinner
@ 2010-01-19 9:18 ` Christoph Hellwig
0 siblings, 0 replies; 7+ messages in thread
From: Christoph Hellwig @ 2010-01-19 9:18 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On Tue, Jan 19, 2010 at 08:03:11PM +1100, Dave Chinner wrote:
> 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.
Yeah, signal is deprecated in favour of sigaction for a reason..
Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 3/3] xfsqa: xfs_check can see stale cached blocks
2010-01-19 9:03 [PATCH 0/3] xfsqa: Fix various test-suite related failures Dave Chinner
2010-01-19 9:03 ` [PATCH 1/3] xfsqa: update 214 golden output Dave Chinner
2010-01-19 9:03 ` [PATCH 2/3] xfsqa: Fix signal usage in aio-dio test code Dave Chinner
@ 2010-01-19 9:03 ` Dave Chinner
2010-01-19 9:19 ` Christoph Hellwig
2 siblings, 1 reply; 7+ messages in thread
From: Dave Chinner @ 2010-01-19 9:03 UTC (permalink / raw)
To: 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.
Signed-off-by: Dave Chinner <david@fromorbit.com>
---
common.rc | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/common.rc b/common.rc
index 6424871..896e38d 100644
--- a/common.rc
+++ b/common.rc
@@ -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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 3/3] xfsqa: xfs_check can see stale cached blocks
2010-01-19 9:03 ` [PATCH 3/3] xfsqa: xfs_check can see stale cached blocks Dave Chinner
@ 2010-01-19 9:19 ` Christoph Hellwig
0 siblings, 0 replies; 7+ messages in thread
From: Christoph Hellwig @ 2010-01-19 9:19 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On Tue, Jan 19, 2010 at 08:03:12PM +1100, Dave Chinner wrote:
> 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.
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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 7+ messages in thread