On 08/16/2012 05:27 PM, Dave Chinner wrote:
On Thu, Aug 16, 2012 at 02:16:28PM -0500, Rich Johnston wrote:
On 07/26/2012 03:35 AM, Dave Chinner wrote:
From: Dave Chinner <dchinner@xxxxxxxxxx>
Unmounting a fileystem mounted on a loop device doesn't always tear
down the loop device. Its racy, and it causes tests to randomly
To avoid that, we have to use umount -d to ensure that we destroy
loop devices under filesystems in case the kernel doesn't tear it
down automatically to prevent the test from failing. However, if
the kernel does tear it down automatically, umount now issues a
warning that it couldn't tear down the loop device because it
couldn't find it, and that causes the test to fail. *facepalm*
So, convert all the loop device unmounts to use -d, and direct the
output of all of them to /dev/null.
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
Test 250 Fails but a bug is already created for this, PV1026237.
News to me. Recording failures in non-public bug trackers, and then
alluding to it via a number that nobody can look up is not very
helpful. If you are going to track mainline kernel
failures/regressions in a bug tracker, please use the oss.sgi.com
bugzilla so that the issues are publicly visible....
Sorry new to the team.
Other than that it looks good and the bug is not related to this
patch, so ...
.... what is the failure you are seeing?
Here is the output from the test and I attached 250.full.
./check -xfs 250
FSTYP -- xfs (non-debug)
PLATFORM -- Linux/x86_64 cxfsxe4 3.6.0-rc1-0.9-default
MKFS_OPTIONS -- -f -bsize=4096 /dev/sdc1
MOUNT_OPTIONS -- /dev/sdc1 /xfs_scratch
250 [failed, exit status 1] - output mismatch (see 250.out.bad)
--- 250.out 2012-08-15 15:01:39.000000000 -0500
+++ 250.out.bad 2012-08-17 07:39:36.000000000 -0500
@@ -11,5 +11,4 @@
*** preallocate large file
*** unmount loop filesystem
*** check loop filesystem
+_check_xfs_filesystem: filesystem on /xfs_test/250.fs is inconsistent
(r) (see 250.full)
Failed 1 of 1 tests
Description: Text document