public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Tomas Racek <tracek@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: xfstests: standard way of handling loop devices
Date: Fri, 10 Aug 2012 08:31:00 +1000	[thread overview]
Message-ID: <20120809223100.GX2877@dastard> (raw)
In-Reply-To: <1855221844.724464.1344501021962.JavaMail.root@redhat.com>

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@fromorbit.com

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

  reply	other threads:[~2012-08-09 22:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1664629800.716769.1344498186489.JavaMail.root@redhat.com>
2012-08-09  8:30 ` xfstests: standard way of handling loop devices Tomas Racek
2012-08-09 22:31   ` Dave Chinner [this message]
2012-08-13 10:43     ` Tomas Racek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120809223100.GX2877@dastard \
    --to=david@fromorbit.com \
    --cc=tracek@redhat.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox