ploop copy receive: don't do fsync()

It will save us a whole couple of seconds for live migration:

With sync:
        Suspend + Dump:   0.22
   Pcopy after suspend:   2.34
        Copy dump file:   0.32
       Undump + Resume:   1.78
                        ------
  Total suspended time:   4.65

Without sync:

        Suspend + Dump:   0.15
   Pcopy after suspend:   0.13
        Copy dump file:   0.32
       Undump + Resume:   1.81
                        ------
  Total suspended time:   2.41

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
ploop_log(): implement subsecond timestamps

Helpful for performance related debugging.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
ploop_log(): make log timestamps conditional

It doesn't make sense to always show timestamps, so let's
do this only when verbosity level is high enough, and
define "high enough" as 4.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
ploop copy: fix usage

Since commit 12117e3 there is no longer standalone ploop-copy binary.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
ploop copy: implement fdatasync before freeze

ploop copy is critical for live migration timing. A recent commit
7aaf33b tried to optimize ploop copy time by removing fsync()
from ploop_receive() after writing the top delta. Apparently,
it was not a good thing to do, because due to the way ploop
works (direct reads bypassing the cache), the delta file must be
fully written on disk, so PLOOP_IOC_ADD_DELTA was causing fsync()
and the end result of that commit was time spent for writing
data was moved from ploop copy to ploop mount on container resume
(adding top delta takes about a second if it's not synced).

So, the fsync (or rather fdatasync) is still required. But we
can optimize the time of fsync by adding yet another one,
done just before we freeze the container, so that most of
the data will be written while container is still running.
The problem is it requires a protocol modification, and such
a modification needs to be backward-compatible.

So this patch adds sending the first 4 bytes of a delta file,
which is interpreted as a "sync me" by the ploop_receive().
Older version of ploop_receive() will just write those bytes
which is useless but harmless.

This patch also rolls back 7aaf33b, because the sync is
still required, and changes fsync() to fdatasync().

Note: we have an ugly 5s wait for the sync to happen.
The protocol is one way so we can't receive "sync finished"
event and therefore we just wait for some time.

TODO: because of this wait, some more data might be written
by the container which is still running. So, ideally, we
should do yet another iteration and another sync,
last time without waiting. Might implement this later.
Current implementation is still an improvement for
containers that don't do much I/O, iterative fdatasync()
might help those that do intensive I/O.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>
ploop tool: add option to set verbosity

Add -v[vvvv], -vN global option to set ploop verbosity. By default, tool
verbosity is set to 3, additional -v options increase it, or one can
specify an absolute value, for example -v0 or even -v-1.

Signed-off-by: Kir Kolyshkin <kir@openvz.org>