ploop_switch_snapshot_ex(): don't show error on ENOENT rm

A failure to remove old top delta is not fatal, plus if
ENOENT is returned it doesn't make sense to even show
the error.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
ploop_is_large_disk_supported(): check ploop module first

A user got the following error:

> # ploop snapshot-switch -u cc0930cb-0e5e-46d8-9f4d-83567ce8fb38 DiskDescriptor.xml
> Opening delta /vz/private/120/root.hdd/root.hdd
> del snapshot {5fbaabe3-6958-40ff-92a7-860e329aab41}
> Adding snapshot {5fbaabe3-6958-40ff-92a7-860e329aab41}
> Storing /vz/private/120/root.hdd/DiskDescriptor.xml.tmp
> Error in do_create_delta (ploop.c:345): Unknown ploop image version: 2

It seems like very old kernel or something else, but the actual reason
is ploop module is not loaded, and it takes a Sherlock Holmes to figure
it out from the provided diagnostics.

So, check first that /sys/module/ploop/parameters is there, and if it's not,
complain once.

Core returned is still the same, as it's supposed to be boolean, but at least
we now have a helpful hint in the output.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
async_send(): call pthread_cond_signal() with mutex locked

From pthread_conf_signal man page:

> The pthread_cond_broadcast() or pthread_cond_signal() functions may  be
> called  by  a  thread  whether  or not it currently owns the mutex that
> threads calling pthread_cond_wait()  or  pthread_cond_timedwait()  have
> associated  with the condition variable during their waits; however, if
> predictable scheduling behavior is required, then that mutex  shall  be
> locked    by    the    thread   calling   pthread_cond_broadcast()   or
> pthread_cond_signal().

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
send_thread(): move mutex lock/unlock out of do/while

As suggested by Maxim, there is no point to release a mutex
and immediately take it again.

Reported-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
ploop mount: add check for host mount opts

As pointed out in bug #3030, ext4 fs that hosts ploop images
should not be mounted with data=writeback as it increases
chances of broken ploop.

This patch adds a check for such mount option -- if it is found
then a warning message is printed once, suggesting to not use it.

https://bugzilla.openvz.org/3030

Reported-by: Devon <devon.b@virtualcomplete.com>
Signed-off-by: Kir Kolyshkin <kir@openvz.org>