losetup -d fails when domU is destroyed

losetup -d fails when domU is destroyed

[Kirk Allan]

I do not see this happen very often, but every once in a while after a domU is destroyed the loop device is still in use.  From the /var/log/messages file I see:

May  8 08:54:00 kdell logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/3/768

In the xen-hotplug.log there is an entry
                             
ioctl: LOOP_CLR_FD: Device or resource busy

It appears that when the /etc/xen/scripts/block script goes to remove the device with the losetup -d “$node” that the device is still busy and the command fails.  But by the time you can enter losetup -d /dev/<loopdevice> from the command line, the device is no longer busy and the command succeeds.

As a test I modified the /etc/xen/scripts/block script to sleep 1 and try the losetup -d again if the first try failed.  After many attempts to cause the problem, it finally happened.  The first losetup -d failed and the second succeeded.  Although this worked, it doesn't seem to be the correct solution to the underlying problem.  Any help or guidance would greatly be appreciated.

Thanks,
Kirk

Re: losetup -d fails when domU is destroyed

[Ewan Mellor]

On Mon, May 08, 2006 at 09:24:26AM -0600, Kirk Allan wrote:

> I do not see this happen very often, but every once in a while after a domU
> is destroyed the loop device is still in use.  From the /var/log/messages
> file I see:
> 
> May 8 08:54:00 kdell logger: /etc/xen/scripts/block: remove
> XENBUS_PATH=backend/vbd/3/768
> 
> In the xen-hotplug.log there is an entry
>                              
> ioctl: LOOP_CLR_FD: Device or resource busy
> 
> It appears that when the /etc/xen/scripts/block script goes to remove the
> device with the losetup -d “$node” that the device is still busy and the
> command fails.  But by the time you can enter losetup -d /dev/<loopdevice>
> from the command line, the device is no longer busy and the command
> succeeds.
> 
> As a test I modified the /etc/xen/scripts/block script to sleep 1 and try
> the losetup -d again if the first try failed.  After many attempts to cause
> the problem, it finally happened.  The first losetup -d failed and the
> second succeeded.  Although this worked, it doesn't seem to be the correct
> solution to the underlying problem.  Any help or guidance would greatly be
> appreciated.

IIRC, we've had people report this before, but no-one's managed to get to the
root cause.  I'd be happy to take a patch that just sleeps and retries a few
times if you can't find the root cause yourself.

You might also speak with Kurt Garloff about bug #374
(http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=374) which is similar,
though in his case the losetup -d failed when the domain had crashed.

Ewan.