Il 27-07-2017 13:09 Igor Cicimov ha scritto:

​And in case of live migration I'm sure the tool you decide to use
will freeze the guest and make sync() call to flush the os cache
*before* stopping and starting the guest on the other node.​


Yeah, I was busy architecting a valid example [1] until I realized that libvirt/KVM surely issues a sync() before live migrating the guest :p

Thank you Igor.


[1] For reference, here you find an example showing as the kernel buffer can sometime act as a writeback cache...

Consider the following command and output:

[root@localhost ~]# dd if=/dev/zero of=/dev/sdb bs=1M count=64
64+0 records in
64+0 records out
67108864 bytes (67 MB) copied, 0.981192 s, 68.4 MB/s

As you can see, write bandwidth is in line with the underlying disk real performance. This means that the close() call (issued by dd just before exiting) flushes the buffers.

Now, let's concurrently open the block device in *read only* mode:

[root@localhost ~]# exec 3</dev/sdb
[root@localhost ~]# dd if=/dev/zero of=/dev/sdb bs=1M count=64
64+0 records in
64+0 records out
67108864 bytes (67 MB) copied, 0.0439497 s, 1.5 GB/s

This time, write bandwidth as reported by dd is about 1.5 GB/s, which is clearly so much more of the disk's real write speed. This means that the close() call returned *before* buffer flushing.

I don't fully understand if, and how, this correlate in read-life with a opened LVM device on top of a DRBD resource in a dual-primary setup. Maybe it opens a small opportunity window for an application writing to a raw block device, and not issuing proper sync/fsync calls, to see stale data in the event of a node migration in a dual-primary setup (without no powerloss or hardware failure happening).

However, this is a very contrived scenario. Moreover, I am not sure on how DRBD interact with kernel's buffers. Time to do some more tests, it seems ... ;)

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8
_______________________________________________
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Reply via email to