Re: [PATCH 4/5] Fix loop test

[Jim Meyering]

Phillip Susi wrote:
> On 12/21/2011 1:53 PM, Jim Meyering wrote:
>>      FAIL: t8000-loop.sh (exit: 1)
>>      =============================
>>      ...
>>      + d1=/h/j/w/co/parted/6/tests/gt-t8000-loop.sh.NpVB/root/dev/loop1
>>      + parted -s
>> /h/j/w/co/parted/6/tests/gt-t8000-loop.sh.NpVB/root/dev/loop1
>> mklabel msdos
>>      + fail=1
>
> I guess you snipped the part with losetup?  It sounds like your kernel
> has the loop driver built as a module, but on Ubuntu it is built in.

It did when I wrote that code, but for the kernel I'm using now,
it is built in.

> I thought that running losetup automatically made the module load, but
> maybe it doesn't?

Back when I added those lines, they really were required.

> Can you make sure that the loop module is loaded
> when you run the test, and that losetup succeeded?
>
> Also, I don't understand the goofy paths there instead of
> /dev/loop1. This must have something to do with that artificial root
> setup in the lvm.sh I didn't quite grok.  It probably shouldn't be
> used in t8000.  I think I'll try to write a proper common loop setup
> function that handles the automatic cleanup the way scsi_debug does.
> Then the other tests can start to migrate from scsi_debug to loop
> instead which will allow them to run in parallel.

I'd really like to have a way to run two or more scsi_debug-using
tests in parallel but that is not possible: the kernel allows only one.

Note that for many of our scsi-debug-using tests, you cannot duplicate
the functionality using a loop device.  Besides, even where you can,
because we don't use e.g., special alignment or block size, you risk
being unable to create a loop device due to inherent limitations, or,
if you create a few because their tests are running in parallel, you
risk perturbing regular processes that (albeit rarely) need to create a
loop device.  That is part of the reason for my using a private-homed
device tree: there I know I'm starting from a clean slate: i.e., far
less risk of interfering with some other loop-creating process.