On Thu, Aug 09, 2012 at 04:30:21AM -0400, Tomas Racek wrote:
> Hi,
>
> I am currently working on tests that check FITRIM implementation (251, 260 and one new I'm writing now) and I want to use loopback device as fallback if $SCRATCH_DEV doesn't support discard. Has anybody been working on some xfstests' standard way of creating/destroying loop devices?
>
> I could do with something as simple as this (in common.rc):
Probably a good idea given the random failures we get with loopback
device unmounting due to the racy unmount-based automatic device
destruction.
>
> _create_loop_device()
> {
> size=${1}
> dev=`losetup -f`
> file="$TEST_DIR/$(basename $dev).fs"
That won't work - we create loop devices with files on the scratch
device, too, and some tests create more than one. This is also racy
in that two threads could both get then same next free loopback
device, but I'm not sure we care about that case very much.
> truncate -s $size $file || _fail "Cannot create image file $file"
It's better to use xfs_io that introduce new external tool
dependencies.
> losetup $dev $file || _fail "Cannot associate $file with $dev"
> echo $dev
> }
>
> _destroy_loop_device()
> {
> dev=${1}
> umount $dev 2>&1
If unmount fails, what then?
> file=`losetup -a | grep $dev | sed -n "s/.*(\(.*\))$/\1/p"`
> losetup -d $dev && rm -f $file || _fail "Cannot destroy loop device"
And if unmount destroys the loop device automatically? That will fail
the test, right?
Also, what happens if we unmount the filesystem first so we can run
consistency checks on the image before we destroy it?
I'd suggest that it is the test's responsibility to create, mount,
unmount, check and destroy the image file as those vary from test to
test. Hence a better idea is to just use an image path/device API.
i.e:
_create_loop_device()
{
file=$1
dev=`losetup -f`
losetup $dev $file || _fail "Cannot associate $file with $dev"
echo $dev
}
_destroy_loop_device()
{
dev=$1
losetup -d $dev || _fail "Cannot destroy loop device"
}
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
