On Wed, Dec 23, 2015 at 10:46:53AM +0300, Denis V. Lunev wrote:
> From: Olga Krishtal <okrish...@virtuozzo.com>
>
> To lock the image file flock (LockFileEx) is used.
> We lock file handle/descriptor. If lock is failed -
> an error is returned.
>
> In win32 realization we can lock reagion of bytes within the file.
> For this reason we at first have to get file size and only than lock it.
>
> Signed-off-by: Olga Krishtal <okrish...@virtuozzo.com>
> Signed-off-by: Denis V. Lunev <d...@openvz.org>
> CC: Kevin Wolf <kw...@redhat.com>
> CC: Max Reitz <mre...@redhat.com>
> CC: Eric Blake <ebl...@redhat.com>
> CC: Fam Zheng <f...@redhat.com>
> ---
> block/raw-posix.c | 15 +++++++++++++++
> block/raw-win32.c | 19 +++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/block/raw-posix.c b/block/raw-posix.c
> index 076d070..6226a5c 100644
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> @@ -33,6 +33,7 @@
> #include "raw-aio.h"
> #include "qapi/util.h"
> #include "qapi/qmp/qstring.h"
> +#include <sys/file.h>
>
> #if defined(__APPLE__) && (__MACH__)
> #include <paths.h>
> @@ -576,6 +577,19 @@ fail:
> return ret;
> }
>
> +static int raw_lock_image(BlockDriverState *bs, BdrvLockImage lock)
> +{
> + int ret;
> + if (lock != BDRV_LOCK_IMAGE_LOCKFILE) {
> + return -ENOTSUP;
> + }
> + ret = flock(((BDRVRawState *)(bs->opaque))->fd, LOCK_EX|LOCK_NB);
> + if (ret != 0) {
> + return -ret;
> + }
> + return ret;
> +}
flock() is a pretty bad choice wrt to NFS. Historically it was often
a no-op. Some impls treat it as a client-local lock and not a server
side lock. Linux apparently now converts flock locks to fcntl locks,
but on NFS only. As a result they'll suffer from the problem that
a close() on any file descriptor pointing to the file will release
the lock. So IMHO both flock() and fcntl() are unusable in practice
from within QEMU, as I don't think it is practical to guarantee
QEMU won't accidentally release the lock by closing another file
descriptor pointing to the same file. If you want to use flock or
fcntl() and provide a strong safety guarantee the only option is to
acquire the locks in a dedicated process prior to giving QEMU access
to the files, which is what libvirt does with its virtlockd daemon.
Regards,
Daniel
[1] http://0pointer.de/blog/projects/locking.html
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
