| Message ID | 550C4951.1030804@sandeen.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 3/20/15 11:22 AM, Eric Sandeen wrote: > If OVERLAYFS=1 is set, then every time we mount the scratch or > test device, set up overlayfs directories under it, and switch > the directory under test to the upper directory. > > This doesn't specifically or directly test overlayfs, it simply > runs the existing tests over it. As such, a few tests fail, > and may be expected to fail due to overlayfs limitations and > caveats. I haven't sorted through the results yet. > > Signed-off-by: Eric Sandeen <sandeen@redhat.com> Zach has almost convinced me that this is the wrong approach and/or not worth doing, or at least not merging. Many of the failures are as a result of this being tacked on, and several tests wouldn't be expected to work at all. So I dunno. What do people think; it's at least interesting on the side, to see what falls off. Good news is, no oopses yet! :) -Eric -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
----- Original Message ----- > From: "Eric Sandeen" <sandeen@sandeen.net> > To: fstests@vger.kernel.org > Sent: Friday, 20 March, 2015 7:57:49 PM > Subject: Re: [PATCH 2/2] fstests: Add overlayfs support > > On 3/20/15 11:22 AM, Eric Sandeen wrote: > > If OVERLAYFS=1 is set, then every time we mount the scratch or > > test device, set up overlayfs directories under it, and switch > > the directory under test to the upper directory. > > > > This doesn't specifically or directly test overlayfs, it simply > > runs the existing tests over it. As such, a few tests fail, > > and may be expected to fail due to overlayfs limitations and > > caveats. I haven't sorted through the results yet. > > > > Signed-off-by: Eric Sandeen <sandeen@redhat.com> > > Zach has almost convinced me that this is the wrong approach and/or > not worth doing, or at least not merging. > > Many of the failures are as a result of this being tacked on, and > several tests wouldn't be expected to work at all. > > So I dunno. What do people think; it's at least interesting on the > side, to see what falls off. > > Good news is, no oopses yet! :) > Well, I agree with Zach. It would be good to have overlayfs, but I think it should be a standalone FS. Overlayfs has some specific things, though. As it needs more directories for work, we can suppose lowerdir is going to be TEST_DIR/SCRATCH_DIR, but what about upperdir? And o we need to be able to explicitly set what filesystem they should be on? Your patch put it all into a single directory, but I think we should be able to test it on different devices. So I would say we need have both, something like _require_test_overlay # basically what your patch do, a single step to make $TEST_DIR in overlay and OVERLAY_UPPER_FS="tmpfs" OVERLAY_LOWER_FS="xfs" _require_scratch_overlay I think we should be able to manipulate with underlying directories directly - though this can be the case only for some specific tests that will do all the work around overlayfs manually. I don't feel to answer this question myself. I'm afraid I'm bringing more question than answers, though. :-)
diff --git a/README b/README index 0c9449a..2b1d023 100644 --- a/README +++ b/README @@ -78,6 +78,8 @@ Preparing system for tests (IRIX and Linux): added to the end of fsstresss and fsx invocations, respectively, in case you wish to exclude certain operational modes from these tests. + - setenv OVERLAYFS "1" to set up an overlay directory after each + test or scratch mount, and run all tests in the upper directory, - or add a case to the switch in common/config assigning these variables based on the hostname of your test diff --git a/common/rc b/common/rc index 22b9a6c..aeca679 100644 --- a/common/rc +++ b/common/rc @@ -200,6 +200,33 @@ _mount_ops_filter() } +# Given a directory, set up 4 subdirectories and create an overlay mount +# on $DIRECTORY/merged +_overlayfs_mount() +{ + local DIR=$1 + # No mkdir -p $DIR/lowerdir; see below + mkdir -p $DIR/upperdir + mkdir -p $DIR/workdir + mkdir -p $DIR/merged + # We make lowerdir the root dir, because at least for the test dev, + # it stands a chance of having content, making overlayfs a bit more + # interesting + mount -t overlay none $SELINUX_MOUNT_OPTIONS \ + -o lowerdir=$DIR/ \ + -o upperdir=$DIR/upperdir \ + -o workdir=$DIR/workdir \ + $DIR/merged +} + +# Expects to get a $DIR which contains the /merged mountpoint +_overlayfs_unmount() +{ + local DIR=$1 + $UMOUNT_PROG $DIR/merged +} + + _scratch_mount_options() { _scratch_options mount @@ -210,10 +237,15 @@ _scratch_mount_options() _scratch_mount() { _mount -t $FSTYP `_scratch_mount_options $*` + if [ -n "$OVERLAYFS" ]; then + _overlayfs_mount $SCRATCH_MNT && SCRATCH_MNT=$SCRATCH_MNT/upperdir + fi } _scratch_unmount() { + SCRATCH_MNT=${SCRATCH_MNT%/upperdir} + _overlayfs_unmount $SCRATCH_MNT $UMOUNT_PROG $SCRATCH_DEV } @@ -227,10 +259,15 @@ _test_mount() { _test_options mount _mount -t $FSTYP $TEST_OPTIONS $TEST_FS_MOUNT_OPTS $SELINUX_MOUNT_OPTIONS $* $TEST_DEV $TEST_DIR + if [ -n "$OVERLAYFS" ]; then + _overlayfs_mount $TEST_DIR && TEST_DIR=$TEST_DIR/upperdir + fi } _test_unmount() { + TEST_DIR=${TEST_DIR%/upperdir} + _overlayfs_unmount $TEST_DIR $UMOUNT_PROG $TEST_DEV } @@ -1679,6 +1716,9 @@ _umount_or_remount_ro() mountpoint=`_is_mounted $device` if [ $USE_REMOUNT -eq 0 ]; then + if [ -n "$OVERLAYFS" ]; then + _overlayfs_unmount $mountpoint + fi $UMOUNT_PROG $device else _remount $device ro @@ -1704,6 +1744,9 @@ _mount_or_remount_rw() echo "!!! failed to remount $device on $mountpoint" return 0 # ok=0 fi + if [ -n "$OVERLAYFS" ]; then + _overlayfs_mount $mountpoint + fi else _remount $device rw fi
If OVERLAYFS=1 is set, then every time we mount the scratch or test device, set up overlayfs directories under it, and switch the directory under test to the upper directory. This doesn't specifically or directly test overlayfs, it simply runs the existing tests over it. As such, a few tests fail, and may be expected to fail due to overlayfs limitations and caveats. I haven't sorted through the results yet. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html