On Thu, 12 Sep 2013 16:27:50 +0200 Kevin Wolf <kw...@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
signature.asc
Description: PGP signature