Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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 at 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 at localhost ~]# exec 3</dev/sdb [root at 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.danti at assyoma.it - info at assyoma.it GPG public key ID: FF5F32A8