[sheepdog] [PATCH 0/9] revive VDI locking mecahnism

Hitoshi Mitake mitake.hitoshi at gmail.com
Wed Jul 16 16:00:30 CEST 2014


At Tue, 15 Jul 2014 15:42:22 +0200,
Valerio Pachera wrote:
> 
> 2014-07-15 15:16 GMT+02:00 Hitoshi Mitake <mitake.hitoshi at gmail.com>:
> 
> >
> > As Valerio points, this problem is not only related to the VDI locking
> > feature. For avoiding this problem, we need to run "dog vdi check"
> > after sudden death of QEMU process or node.
> >
> 
> Ok, that's good to know.
> 
> So a sudden death of qemu will just leave the lock that may be removed by
> vdi check or a new command if required.
> So, generally speaking: if I try to run a guest and qemu  exits with an
> error complaining about the lock, it means another process is currently
> using it;
> if I don't find this process, it means a qemu process has die previously
> and I need to run vdi check.
> 
> That sounds more safe than before because I may have run the guest without
> knowing the vdi may be in an inconsistent state because of a crash I didn't
> know of.

Yes, your understanding is correct. When a new QEMU fails to acquire a
lock of VDI, there are two possibilities:
1. other process (QEMU or tgt) is using it
2. previous process which used it died suddenly

> 
> The down side of is that the bigger the vdi, the longer the time for the
> check, but that is unrelated to the vdi locking patch.
> 
> One more question:
> kill -15 vs kill -9:
> Is kill -15 going to terminate qemu in a "sweet" way, so it flushed it's
> data and remove the lock before dieing? Or does it have the same effect
> (from the lock point of view) of a kill -15?

I don't know the behavior of QEMU. I'll test it and report later.

Thanks,
Hitoshi



More information about the sheepdog mailing list