Re: [Xen-devel] [PATCH] libxl: do not call default block script

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-05-10 at 15:29 +0100, Roger Pau Monne wrote:
> On 10/05/13 16:21, Ian Campbell wrote:
> > On Fri, 2013-05-10 at 15:19 +0100, Roger Pau Monne wrote:
> >> On 08/05/13 07:07, Marek Marczykowski wrote:
> >>> When user didn't specified disk->script, libxl writes physical-device
> >>> node itself, making script call redundant - especially the default one.
> >>
> >> This change will break NetBSD support, please also attach the necessary
> >> NetBSD change or at least mention it in the commit message, so it can be
> >> fixed.
> > 
> > I hadn't thought about NetBSD. This strongly suggests that if it is
> > appropriate at all it is most definitely 4.4 material since it has
> > non-obvious affects.
> > 
> >> If I'm right, the block script does other things apart from writing the
> >> physical device major/minor, it also checks that no other domain is
> >> using this device.
> > 
> > I nearly said that too but at least in the Linux scripts the presence of
> > the physical-device node cause the script to exit before that check.
> > Oops.
> 
> Ooops, I should have looked at the actual script before speaking so
> quickly. It looks like this might cause trouble, specially because we no
> longer check that the block device is not opened by two guests at the
> same time, IMHO the right solution would be to prevent libxl from
> writing the physical-device entry at all, and I'm not sure if this
> shouldn't be considered as a bug fix for 4.3.

I seem to vaguely recall some trouble in this area when it was
implemented, which makes me wary of changing it at this stage.

I think it broken localhost live migration or something like that. I
imagine your new hotplug script work will end up also fixing that as a
by-product?

> NetBSD for example prevents a block device from being opened more than
> once at the same time, but I don't think Linux does this.

I think only if you use O_EXCL.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel