* [Qemu-devel] [RFC] O_EXCL or not open block device
@ 2013-09-12 11:27 Jack Wang
2013-09-12 13:58 ` Stefan Hajnoczi
0 siblings, 1 reply; 6+ messages in thread
From: Jack Wang @ 2013-09-12 11:27 UTC (permalink / raw)
To: Dongsu Park, qemu-devel; +Cc: kwolf, Paolo Bonzini, NeilBrown, Stefan Hajnoczi
Hi all,
We're using qemu export md-raid to guest OS, and we saw deadlock on
MD(which is already fixed by Neil), please see thread below:
> http://marc.info/?l=linux-raid&m=137894040228125&w=2
As Neil suggested it would be good for userspace applications to call
open() with O_EXCL flag, to avoid such MD hanging problems at the begining.
And we checked qemu, it looks it doesn't include O_EXCL flag when open
block device.
After search in the mail list we found there are a similar discussion:
https://lists.nongnu.org/archive/html/qemu-devel/2011-04/msg00722.html
> To O_EXCL or not to O_EXCL open host_cdrom
Which looks prefer enable O_EXCL, but I checked latest qemu tree, there
no such code, could anyone give comments on this?
Best regards,
Jack
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] O_EXCL or not open block device
2013-09-12 11:27 [Qemu-devel] [RFC] O_EXCL or not open block device Jack Wang
@ 2013-09-12 13:58 ` Stefan Hajnoczi
2013-09-12 14:27 ` Kevin Wolf
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Hajnoczi @ 2013-09-12 13:58 UTC (permalink / raw)
To: Jack Wang; +Cc: kwolf, Paolo Bonzini, NeilBrown, Dongsu Park, qemu-devel
On Thu, Sep 12, 2013 at 01:27:32PM +0200, Jack Wang wrote:
> Hi all,
>
> We're using qemu export md-raid to guest OS, and we saw deadlock on
> MD(which is already fixed by Neil), please see thread below:
> > http://marc.info/?l=linux-raid&m=137894040228125&w=2
>
> As Neil suggested it would be good for userspace applications to call
> open() with O_EXCL flag, to avoid such MD hanging problems at the begining.
>
> And we checked qemu, it looks it doesn't include O_EXCL flag when open
> block device.
>
> After search in the mail list we found there are a similar discussion:
>
> https://lists.nongnu.org/archive/html/qemu-devel/2011-04/msg00722.html
>
> > To O_EXCL or not to O_EXCL open host_cdrom
>
> Which looks prefer enable O_EXCL, but I checked latest qemu tree, there
> no such code, could anyone give comments on this?
Continuing from that discussion, I think the shared CD-ROM case is
something we must avoid breaking. It worked in the past so it shouldn't
break in a new QEMU version.
Kevin: Do you think we should add an option to the host_device
BlockDriver that sets the O_EXCL open flag? That way users and new
libvirt can use O_EXCL for host block devices.
The simpler alternative is to always use O_EXCL for non-CDROM host
devices. Simple patch, no configuration required, but it means we
continue to lack O_EXCL on CD-ROMs.
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] O_EXCL or not open block device
2013-09-12 13:58 ` Stefan Hajnoczi
@ 2013-09-12 14:27 ` Kevin Wolf
2013-09-12 15:57 ` Jack Wang
2013-09-12 22:48 ` NeilBrown
0 siblings, 2 replies; 6+ messages in thread
From: Kevin Wolf @ 2013-09-12 14:27 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: NeilBrown, Jack Wang, Paolo Bonzini, Dongsu Park, qemu-devel
Am 12.09.2013 um 15:58 hat Stefan Hajnoczi geschrieben:
> On Thu, Sep 12, 2013 at 01:27:32PM +0200, Jack Wang wrote:
> > Hi all,
> >
> > We're using qemu export md-raid to guest OS, and we saw deadlock on
> > MD(which is already fixed by Neil), please see thread below:
> > > http://marc.info/?l=linux-raid&m=137894040228125&w=2
> >
> > As Neil suggested it would be good for userspace applications to call
> > open() with O_EXCL flag, to avoid such MD hanging problems at the begining.
> >
> > And we checked qemu, it looks it doesn't include O_EXCL flag when open
> > block device.
> >
> > After search in the mail list we found there are a similar discussion:
> >
> > https://lists.nongnu.org/archive/html/qemu-devel/2011-04/msg00722.html
> >
> > > To O_EXCL or not to O_EXCL open host_cdrom
> >
> > Which looks prefer enable O_EXCL, but I checked latest qemu tree, there
> > no such code, could anyone give comments on this?
>
> Continuing from that discussion, I think the shared CD-ROM case is
> something we must avoid breaking. It worked in the past so it shouldn't
> break in a new QEMU version.
>
> Kevin: Do you think we should add an option to the host_device
> BlockDriver that sets the O_EXCL open flag? That way users and new
> libvirt can use O_EXCL for host block devices.
>
> The simpler alternative is to always use O_EXCL for non-CDROM host
> devices. Simple patch, no configuration required, but it means we
> continue to lack O_EXCL on CD-ROMs.
I'm not sure why O_EXCL would be correct on generic block devices when
it's wrong on CD-ROMs. I think it's in fact more likely that other
devices are shared, as backing files.
Adding an option is certainly possible, but what would the default be?
If O_EXCL is off by default, would anyone actually use it?
Kevin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] O_EXCL or not open block device
2013-09-12 14:27 ` Kevin Wolf
@ 2013-09-12 15:57 ` Jack Wang
2013-09-12 22:48 ` NeilBrown
1 sibling, 0 replies; 6+ messages in thread
From: Jack Wang @ 2013-09-12 15:57 UTC (permalink / raw)
To: Kevin Wolf
Cc: NeilBrown, Paolo Bonzini, Dongsu Park, Stefan Hajnoczi,
qemu-devel
On 09/12/2013 04:27 PM, Kevin Wolf wrote:
> Am 12.09.2013 um 15:58 hat Stefan Hajnoczi geschrieben:
>> On Thu, Sep 12, 2013 at 01:27:32PM +0200, Jack Wang wrote:
>>> Hi all,
>>>
>>> We're using qemu export md-raid to guest OS, and we saw deadlock on
>>> MD(which is already fixed by Neil), please see thread below:
>>>> http://marc.info/?l=linux-raid&m=137894040228125&w=2
>>>
>>> As Neil suggested it would be good for userspace applications to call
>>> open() with O_EXCL flag, to avoid such MD hanging problems at the begining.
>>>
>>> And we checked qemu, it looks it doesn't include O_EXCL flag when open
>>> block device.
>>>
>>> After search in the mail list we found there are a similar discussion:
>>>
>>> https://lists.nongnu.org/archive/html/qemu-devel/2011-04/msg00722.html
>>>
>>>> To O_EXCL or not to O_EXCL open host_cdrom
>>>
>>> Which looks prefer enable O_EXCL, but I checked latest qemu tree, there
>>> no such code, could anyone give comments on this?
>>
>> Continuing from that discussion, I think the shared CD-ROM case is
>> something we must avoid breaking. It worked in the past so it shouldn't
>> break in a new QEMU version.
>>
>> Kevin: Do you think we should add an option to the host_device
>> BlockDriver that sets the O_EXCL open flag? That way users and new
>> libvirt can use O_EXCL for host block devices.
>>
>> The simpler alternative is to always use O_EXCL for non-CDROM host
>> devices. Simple patch, no configuration required, but it means we
>> continue to lack O_EXCL on CD-ROMs.
>
> I'm not sure why O_EXCL would be correct on generic block devices when
> it's wrong on CD-ROMs. I think it's in fact more likely that other
> devices are shared, as backing files.
>
> Adding an option is certainly possible, but what would the default be?
> If O_EXCL is off by default, would anyone actually use it?
>
> Kevin
>
Hi Kevin,
Could you elaborate more about why you think it's wrong to use O_EXCL on
block device?
There are already quite a lot different options in qemu, if there is
such new option, people who care about it will use it I believe.
Thanks
Jack
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] O_EXCL or not open block device
2013-09-12 14:27 ` Kevin Wolf
2013-09-12 15:57 ` Jack Wang
@ 2013-09-12 22:48 ` NeilBrown
2013-09-13 7:16 ` Paolo Bonzini
1 sibling, 1 reply; 6+ messages in thread
From: NeilBrown @ 2013-09-12 22:48 UTC (permalink / raw)
To: Kevin Wolf
Cc: Jack Wang, Paolo Bonzini, Dongsu Park, Stefan Hajnoczi,
qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]
On Thu, 12 Sep 2013 16:27:50 +0200 Kevin Wolf <kwolf@redhat.com> wrote:
> Am 12.09.2013 um 15:58 hat Stefan Hajnoczi geschrieben:
> > On Thu, Sep 12, 2013 at 01:27:32PM +0200, Jack Wang wrote:
> > > Hi all,
> > >
> > > We're using qemu export md-raid to guest OS, and we saw deadlock on
> > > MD(which is already fixed by Neil), please see thread below:
> > > > http://marc.info/?l=linux-raid&m=137894040228125&w=2
> > >
> > > As Neil suggested it would be good for userspace applications to call
> > > open() with O_EXCL flag, to avoid such MD hanging problems at the begining.
> > >
> > > And we checked qemu, it looks it doesn't include O_EXCL flag when open
> > > block device.
> > >
> > > After search in the mail list we found there are a similar discussion:
> > >
> > > https://lists.nongnu.org/archive/html/qemu-devel/2011-04/msg00722.html
> > >
> > > > To O_EXCL or not to O_EXCL open host_cdrom
> > >
> > > Which looks prefer enable O_EXCL, but I checked latest qemu tree, there
> > > no such code, could anyone give comments on this?
> >
> > Continuing from that discussion, I think the shared CD-ROM case is
> > something we must avoid breaking. It worked in the past so it shouldn't
> > break in a new QEMU version.
> >
> > Kevin: Do you think we should add an option to the host_device
> > BlockDriver that sets the O_EXCL open flag? That way users and new
> > libvirt can use O_EXCL for host block devices.
> >
> > The simpler alternative is to always use O_EXCL for non-CDROM host
> > devices. Simple patch, no configuration required, but it means we
> > continue to lack O_EXCL on CD-ROMs.
>
> I'm not sure why O_EXCL would be correct on generic block devices when
> it's wrong on CD-ROMs. I think it's in fact more likely that other
> devices are shared, as backing files.
O_EXCL make sense if you or someone else might change the contents.
If the device is read-only, or is uniformly treated as read-only, then O_EXCL
is unnecessary and could definitely get in the way.
I would be nice if we had O_SHARED and O_EXCL, but unfortunately we don't....
I wonder if O_EXCL|O_RDONLY could be treated as a shared lock.... Maybe one
day.
>
> Adding an option is certainly possible, but what would the default be?
> If O_EXCL is off by default, would anyone actually use it?
I would suggest the default would be to use O_EXCL iff opening with WRITE
access.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [RFC] O_EXCL or not open block device
2013-09-12 22:48 ` NeilBrown
@ 2013-09-13 7:16 ` Paolo Bonzini
0 siblings, 0 replies; 6+ messages in thread
From: Paolo Bonzini @ 2013-09-13 7:16 UTC (permalink / raw)
To: NeilBrown; +Cc: Kevin Wolf, Jack Wang, Dongsu Park, Stefan Hajnoczi, qemu-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 13/09/2013 00:48, NeilBrown ha scritto:
>> I'm not sure why O_EXCL would be correct on generic block
>> devices when it's wrong on CD-ROMs. I think it's in fact more
>> likely that other devices are shared, as backing files.
>
> O_EXCL make sense if you or someone else might change the contents.
> If the device is read-only, or is uniformly treated as read-only,
> then O_EXCL is unnecessary and could definitely get in the way. I
> would be nice if we had O_SHARED and O_EXCL, but unfortunately we
> don't.... I wonder if O_EXCL|O_RDONLY could be treated as a shared
> lock.... Maybe one day.
Even that won't really work well for CD-ROM passthrough, because
ejecting a CD certainly affects the other openers but is available
with O_RDONLY.
A policy on sharing block devices that are used "just for the data"
does not belong in QEMU, it belongs in management. As such, I don't
think that QEMU should blindly use O_EXCL on all block devices.
My patch series used O_EXCL for CD-ROMs only to disable kernel event
polling; in other words, basically as a workaround. There are other
reasons why not sharing a host CD unit makes sense; for example, ATAPI
event polling is edge-triggered and simply doesn't work with multiple
VMs attached. But if the sharing policy could be left exclusively to
management above QEMU, it would be better to do so.
I think if someone wants to attach a real CD-ROM disc to a VM just for
the data (e.g. ejecting the disc will not open the real tray) they
should use something like "file:/dev/sr0". Then QEMU would not use
O_EXCL even with my patch series.
Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSMrvAAAoJEBvWZb6bTYbyZZMQAJIxy9jeo7/mKKrchvMs8uRY
3xN4IYtEJX15tAymsBCybW4t1Vr6P+N6I6zlFhdNCpY+o8Sckm5RV1a+1dJp5cz4
6JhAnEeddoZeEzBZorcpRCLkRZwiX2lECNsD2+cakXhprn5I+Mphd9xLBHb7FMZA
eRKn3Fe4+wAFXXqanzy8SxjK7S6IN+0su6mfKqQF94HxLVM9f2EBlfFm20rUJ4jS
PEhSJ2kPVMvanfDGUYzIfwP/eMBKJ8+95jBpcw1YBjn1U1V1c5wLguSyHGUacs8G
sOc0X20vuK0bF9oMFYvkMaQHEnwKvNWg640pkqzWe4F2Oe73pim7kVAJzQGD4+s5
SnglMBsH+0wjA85KPwJOD3+Tv58mTbTLiQDQVC/hX9p1JCZPeptXYEiYhcNwWHWF
RGM87PB9QuopE2TQJnRCPUDz9oZDX25cscZwKbsWriHAwTub4+PGm2LTARwC5ByM
0v+QCEzE7FmqEuE4K680iwKKVVWP/x1Mqn8/XW27+liOpL2FgBsPZDn27YcKQGlc
UOHLs1X0g/4CSHNq4LacthgPNihNnLQ9TwZiO+P9HimpnfjWW3KfkxjvqaaWANot
Tg13mS1GpxagXY675keddSLQ7GdBHkDh64R4hUzSmjrg/j9UQKChXz9ycArZ4b+t
zEZy1H/cLiwwzEUm8hj8
=6pli
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-13 7:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-12 11:27 [Qemu-devel] [RFC] O_EXCL or not open block device Jack Wang
2013-09-12 13:58 ` Stefan Hajnoczi
2013-09-12 14:27 ` Kevin Wolf
2013-09-12 15:57 ` Jack Wang
2013-09-12 22:48 ` NeilBrown
2013-09-13 7:16 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).