Mailing List Archive: blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...)

blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...)

May 1, 2007, 7:48 PM

Post #1 of 6 (78 views)

I don't know why I'm the only one to see this, but blktap hasn't been
working for me since 14895:800aa9f5cec9. Opening /var/run/tap/blktap0
fails. I think this is because the kernel defines BLKTAP_DEV_DIR as
/dev/xen in drivers/xen/blktap/blktap.c, but in that changeset the
tools define it as /var/run/tap in tools/blktap/lib/blktaplib.h.

Reverting the change to blktaplib.h gives me blktap devices
again. Reads and writes don't seem to make any progress. I'll keep
investigating, but any clues would be welcome.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...) [ In reply to ]

keir at xensource

May 2, 2007, 5:51 AM

Post #2 of 6 (76 views)

On 2/5/07 03:48, "Brendan Cully" <brendan@cs.ubc.ca> wrote:

> I don't know why I'm the only one to see this, but blktap hasn't been
> working for me since 14895:800aa9f5cec9. Opening /var/run/tap/blktap0
> fails. I think this is because the kernel defines BLKTAP_DEV_DIR as
> /dev/xen in drivers/xen/blktap/blktap.c, but in that changeset the
> tools define it as /var/run/tap in tools/blktap/lib/blktaplib.h.
>
> Reverting the change to blktaplib.h gives me blktap devices
> again. Reads and writes don't seem to make any progress. I'll keep
> investigating, but any clues would be welcome.

More likely it's simply because /var/run/tap/ doesn't exist?

Either some startup script needs to 'mkdir -p', or blktapctrl needs to make
the directory on demand.

-- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...) [ In reply to ]

May 2, 2007, 8:11 AM

Post #3 of 6 (78 views)

On Wednesday, 02 May 2007 at 13:51, Keir Fraser wrote:
> On 2/5/07 03:48, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
>
> > I don't know why I'm the only one to see this, but blktap hasn't been
> > working for me since 14895:800aa9f5cec9. Opening /var/run/tap/blktap0
> > fails. I think this is because the kernel defines BLKTAP_DEV_DIR as
> > /dev/xen in drivers/xen/blktap/blktap.c, but in that changeset the
> > tools define it as /var/run/tap in tools/blktap/lib/blktaplib.h.
> >
> > Reverting the change to blktaplib.h gives me blktap devices
> > again. Reads and writes don't seem to make any progress. I'll keep
> > investigating, but any clues would be welcome.
>
> More likely it's simply because /var/run/tap/ doesn't exist?
>
> Either some startup script needs to 'mkdir -p', or blktapctrl needs to make
> the directory on demand.

the blktap tools do create that directory on demand, and in fact
/var/run/tap/blktap0 is properly created. What fails is the 'open',
somewhere in the kernel I believe. Maybe this only affects
block-attaching a device in domain 0?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...) [ In reply to ]

keir at xensource

May 2, 2007, 8:19 AM

Post #4 of 6 (76 views)

On 2/5/07 16:11, "Brendan Cully" <brendan@cs.ubc.ca> wrote:

>> More likely it's simply because /var/run/tap/ doesn't exist?
>>
>> Either some startup script needs to 'mkdir -p', or blktapctrl needs to make
>> the directory on demand.
>
> the blktap tools do create that directory on demand, and in fact
> /var/run/tap/blktap0 is properly created. What fails is the 'open',
> somewhere in the kernel I believe. Maybe this only affects
> block-attaching a device in domain 0?

The open() that's part of mkfifo()? Those FIFO files have nothing to do with
the blktap kernel module, I believe, in which case this can't have anything
to do with a mismatch of something between blktap user and blktap kernel.

-- Keir

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...) [ In reply to ]

May 2, 2007, 8:35 AM

Post #5 of 6 (78 views)

On Wednesday, 02 May 2007 at 16:19, Keir Fraser wrote:
>
>
>
> On 2/5/07 16:11, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
>
> >> More likely it's simply because /var/run/tap/ doesn't exist?
> >>
> >> Either some startup script needs to 'mkdir -p', or blktapctrl needs to make
> >> the directory on demand.
> >
> > the blktap tools do create that directory on demand, and in fact
> > /var/run/tap/blktap0 is properly created. What fails is the 'open',
> > somewhere in the kernel I believe. Maybe this only affects
> > block-attaching a device in domain 0?
>
> The open() that's part of mkfifo()? Those FIFO files have nothing to do with
> the blktap kernel module, I believe, in which case this can't have anything
> to do with a mismatch of something between blktap user and blktap kernel.

The open of blktap0 (the character device).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...) [ In reply to ]

May 2, 2007, 9:44 AM

Post #6 of 6 (76 views)

The attached patch fixes the problem for me (well, my qcow tapdisk is
still hanging, but that's a separate issue).