Btrfs devel - Jun 2013 - [PATCH] xfstests: check if the scratch dev pool is mounted in _require_scratch

If you use the SCRATCH_DEV_POOL for btrfs you will end up with the command line
like this

mkfs.btrfs $SCRATCH_DEV_POOL $SCRATCH_DEV

and btrfs does this thing where it makes the lowest valued device id show up in
/proc/mounts no matter which device you specify at the mount command.  So in
this case mount will show the first device in $SCRATCH_DEV_POOL instead of
$SCRATCH_DEV, so anybody who wants to just use the scratch mnt with the scratch
dev will fail to work because we never unmount the scratch mount.  Fix this by
checking to see if the scratch dev pool is mounted at scratch mnt and unmount it
so we can run our test.  This fixes the issue I was seeing by running

./check btrfs/307 generic/015

Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
---
 common/rc |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/common/rc b/common/rc
index ad7cbc9..7e03400 100644
--- a/common/rc
+++ b/common/rc
@@ -938,6 +938,8 @@ _supported_os()
 #
 _require_scratch()
 {
+    local i
+
     case "$FSTYP" in
 	nfs*)
 		 echo $SCRATCH_DEV | grep -q ":" > /dev/null 2>&1
@@ -978,6 +980,17 @@ _require_scratch()
             exit 1
         fi
     fi
+
+    # we may have a scratch dev pool specified, so make sure it''s been
unmounted
+    # from the scratch mount
+    for i in $SCRATCH_DEV_POOL; do
+        if _mount | grep $i | grep -q $SCRATCH_MNT; then
+            if ! $UMOUNT_PROG $i; then
+                echo "failed to umount $i - aborting"
+                exit 1
+            fi
+        fi
+    done
 }
 
 # this test needs a logdev
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

> $SCRATCH_DEV, so anybody who wants to just use the scratch mnt with the
scratch
> dev will fail to work because we never unmount the scratch mount.
Yeah, this is annoying.
> Fix this by
> checking to see if the scratch dev pool is mounted at scratch mnt and
unmount it
> so we can run our test.  This fixes the issue I was seeing by running
But this fix seems bonkers.  Can we have _scratch_unmount unmount the
mountpoint instead of the device?  That''s what Eric suggested when I
whined about this a while ago.

- z

index fe6bbfc..481486a 100644
--- a/common/rc
+++ b/common/rc
@@ -280,7 +280,7 @@ _scratch_mount()
 
 _scratch_unmount()
 {
-    $UMOUNT_PROG $SCRATCH_DEV
+    $UMOUNT_PROG $SCRATCH_MNT
 }
 
 _scratch_remount()

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

On Wed, Jun 26, 2013 at 12:18:04PM -0700, Zach Brown
wrote:
> > $SCRATCH_DEV, so anybody who wants to just use the scratch mnt with
the scratch
> > dev will fail to work because we never unmount the scratch mount.
> 
> Yeah, this is annoying.
> 
> > Fix this by
> > checking to see if the scratch dev pool is mounted at scratch mnt and
unmount it
> > so we can run our test.  This fixes the issue I was seeing by running
> 
> But this fix seems bonkers.  Can we have _scratch_unmount unmount the
> mountpoint instead of the device?  That''s what Eric suggested when
I
> whined about this a while ago.
> 
Well actually we probably need both, since we need callers of _scratch_umount to
actually work.  But my patch is slightly wrong, I need to be making sure the
device is actually mounted at scratch mnt before I unmount it, otherwise error
out.  Thanks,

Josef

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs