On Tue, 2011-03-08 at 14:29 +0100, Boris Ranto wrote: > On Mon, 2011-03-07 at 14:12 -0600, Alex Elder wrote: > > On Mon, 2011-03-07 at 16:25 +0100, Boris Ranto wrote: > > > Nfs tries to umount $testdir in _cleanup_testdir function. The test 135 calls the function from directory $SCRATCH_MNT that is equal to $testdir (at least for nfs). The umount will therefore fail causing the test to fail due to the output mismatch. > > > > > > This simple patch fixes the issue for me. > > > > > > Signed-off-by: Boris Ranto <branto@xxxxxxxxxx> > > > > This looks OK to me. Most other tests do this chdir > > in their cleanup function. > > > > I did a quick scan and found that test 126 may suffer the > > same problem. Can you check this? We could include the > > fix for both tests in the same commit. > > > > Yes, the test needs cd /, too. Actually the test 126 also does double > umount thanks to the _cleanup before exit and the trap command. So the > removal of the call of the _cleanup function before exit is necessary, > too. I will commit this patch, fixing the problems in 126 and 135. I'll massage the commit message a bit to fit what it does, and the your discussion here. I'm not going to do anything (at the moment) about the double mount/umount issues you mention. Thanks for submitting the fixes. -Alex > > > > It also looks to me like tests 069, 089 might have a > > similar issue if they get interrupted. > > Yes, that's also true, if the tests are interrupted and then immediately > run again the umount will fail due to the processes in background but > I'm not sure whether it is worth fixing (and if there is a good way to > fix it). > I've had bigger problems with double mount/umount in several tests > (namely: double umount - 124, 128, double mount - 129, 130). The double > umounts occur due to the use of trapped _cleanup and umount $SCRATCH_MNT > in the tests. The double mounts occur due to the use of _setup_testdir > and _scratch_mount (both of them mount $SCRATCH_MNT in the nfs case). > The problem is that I'm not sure how to fix these without any change in > the behaviour. > > > > > -Alex > > . . . _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
