Re: Re: Question on "xen-blkfront: handle Xen major numbers other than XENVBD"

[Stefan Bader <stefan.bader@canonical.com>]

On 13.07.2011 15:20, Stefano Stabellini wrote:
> On Wed, 13 Jul 2011, Stefan Bader wrote:
>> On 13.07.2011 12:54, Ian Campbell wrote:
>>> On Wed, 2011-07-13 at 11:47 +0100, Stefano Stabellini wrote:
>>>> On Wed, 13 Jul 2011, Stefan Bader wrote:
>>>>> This is /me trying to understand the background of
>>>>>
>>>>> commit c80a420995e721099906607b07c09a24543b31d9
>>>>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>>> Date:   Thu Dec 2 17:55:00 2010 +0000
>>>>>
>>>>>     xen-blkfront: handle Xen major numbers other than XENVBD
>>>>>
>>>>> My guess would be that it has its reason from running HVM guests. The issue I in
>>>>> some way hear in complaints is, that running as PVM guest (at least) people seem
>>>>> to have used for example "sda1" in the instance configuration and then relied on
>>>>> the device being called that way within the instance. Now it is suddenly called
>>>>> "xvde1".
>>>>> This is maybe a broken assumption in the first place, and not that hard to cope
>>>>> with (its just surprising and maybe breaks some automation). I mainly want to
>>>>> understand the reasoning, so I can explain it where I get asked.
>>>>
>>>> The rationale behind this is that it wouldn't be correct for
>>>> xen-blkfront to "steal" the major number of the scsi, sata or ide
>>>> subsystems.
>>>
>>> It should be pointed out that the out of mainline "classic" PV Xen
>>> patches do exactly that (although I at least have been discouraging the
>>> use of this configuration for many years now). But it's not something we
>>> felt would fly with upstream.
>>>
>>> Ian.
>>>
>>
>> It is certainly desirable not to take the major numbers from other subsystems.
>> And it seems I was confused by switching between older and newer driver
>> versions. So saying "sda1" in the configuration _was_ already converted into
>> "xvda1" and it was using the major of xvd. The surprising change was in that
>> case that "sda1" now converts into "xvde1" (and funnily "hda1" seems to become
>> "xvda", not "xvda1"). Though I think this is required to have a sane mapping
>> when people mix hdx and sdx in the configuration.
> 
> Actually this is a very tricky issue.
> 
> The problem is that if we translate "sda1" into "xvda1" then what
> happens if a users specifies both "sda1" and "hda1"? Of course there is
> going to be a conflict and the guest won't boot.
> In order to avoid the problem, xen-blkfront starts naming pv disks
> corresponding to "sd" disks from xvde onwards and pv disks corresponding
> to "hd" disks from xvda onwards.
> 
> Initially we thought of naming pv disks corresponding to emulated disks
> (both hd and sd) in a very unique way, so that they could never clash
> with normal pv disks, something like xvdHDa1. However it was very
> confusing to users so we decided to remove it and go for a simple
> hda->xvda conversion. However the sda conversion remained 4 letters off
> to avoid clashes with hda.
> I guess we could remove that offset as well and make both hda and sda
> correspond to xvda. Maybe easier to guess from the user POV but also
> easier to create conflicts.
> 
> What do you think?
> 
Yeah, I understand the problem now that I thought of the possibility of having
both name types in the configuration. Though I could imagine that in reality
there will be no one having that done as it would have caused problems...
As you say, the only way to avoid any clashed is to have seperate namespaces.
But that again is unexpected now and people would complain.
The 4 letters offset probably still can get busted if someone decides to use hde
and sda. Detecting clashes at allocation time and then using another name for
the duplicate is likely to result in a random of the two to be the secondary.
My feeling would be that trying to map two namespaces into one will always be
confusing and/or failing to some degree. The reason to go back would only be
that this was broken before, so it can probably be expected that people have
avoided that mix.So it would be as it has been before. But I bet there are other
people that thought of it as a bug... Not an easy decision at all.

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