On Wed, Apr 13, 2016 at 05:09:49PM +0800, Fam Zheng wrote:
> Underneath is the fcntl syscall that locks the local file, similar to what is
> already used in libvirt virtlockd. Also because of that, we cannot directly
> apply fcntl lock on the image file itself, instead we open and lock
> "/var/tm
On 04/14/2016 08:46 AM, Fam Zheng wrote:
On Thu, 04/14 08:04, Denis V. Lunev wrote:
unfortunately no. If the lock will be on the image file,
we will have get it on the target node on QEMU start
and re-acquire it in bdrv_invalidate_cache.
From my POW you should not get the lock if
BDRV_O_INACTI
On 04/14/2016 09:23 AM, Fam Zheng wrote:
On Thu, 04/14 09:14, Denis V. Lunev wrote:
On 04/14/2016 08:46 AM, Fam Zheng wrote:
On Thu, 04/14 08:04, Denis V. Lunev wrote:
unfortunately no. If the lock will be on the image file,
we will have get it on the target node on QEMU start
and re-acquire i
On Thu, 04/14 09:14, Denis V. Lunev wrote:
> On 04/14/2016 08:46 AM, Fam Zheng wrote:
> >On Thu, 04/14 08:04, Denis V. Lunev wrote:
> >>unfortunately no. If the lock will be on the image file,
> >>we will have get it on the target node on QEMU start
> >>and re-acquire it in bdrv_invalidate_cache.
>
On Thu, 04/14 08:04, Denis V. Lunev wrote:
> unfortunately no. If the lock will be on the image file,
> we will have get it on the target node on QEMU start
> and re-acquire it in bdrv_invalidate_cache.
>
> From my POW you should not get the lock if
> BDRV_O_INACTIVE is set.
That is what I meant.
On 04/14/2016 05:36 AM, Fam Zheng wrote:
On Wed, 04/13 13:18, Denis V. Lunev wrote:
On 04/13/2016 12:09 PM, Fam Zheng wrote:
Too many troubles have been caused by two processes writing to the same image
unexpectedly. This series introduces automatical image locking into QEMU to
avoid such trage
On Wed, 04/13 13:18, Denis V. Lunev wrote:
> On 04/13/2016 12:09 PM, Fam Zheng wrote:
> >Too many troubles have been caused by two processes writing to the same image
> >unexpectedly. This series introduces automatical image locking into QEMU to
> >avoid such tragedy. With this, the user won't be a
On Wed, 04/13 10:19, Daniel P. Berrange wrote:
> On Wed, Apr 13, 2016 at 05:09:49PM +0800, Fam Zheng wrote:
> > Too many troubles have been caused by two processes writing to the same
> > image
> > unexpectedly. This series introduces automatical image locking into QEMU to
> > avoid such tragedy.
On 04/13/2016 12:09 PM, Fam Zheng wrote:
Too many troubles have been caused by two processes writing to the same image
unexpectedly. This series introduces automatical image locking into QEMU to
avoid such tragedy. With this, the user won't be able to open the image from
two processes (e.g. using
On Wed, Apr 13, 2016 at 05:09:49PM +0800, Fam Zheng wrote:
> Too many troubles have been caused by two processes writing to the same image
> unexpectedly. This series introduces automatical image locking into QEMU to
> avoid such tragedy. With this, the user won't be able to open the image from
> t
Too many troubles have been caused by two processes writing to the same image
unexpectedly. This series introduces automatical image locking into QEMU to
avoid such tragedy. With this, the user won't be able to open the image from
two processes (e.g. using qemu-img when the image is attached to the
11 matches
Mail list logo
