Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Jul 27, 2017 at 9:04 PM, Igor Cicimov < igorc at encompasscorporation.com> wrote: > Hey Gionatan, > > On Thu, Jul 27, 2017 at 7:04 PM, Gionatan Danti <g.danti at assyoma.it> > wrote: > >> Il 27-07-2017 10:23 Igor Cicimov ha scritto: >> >>> >>> When in cluster mode LVM will not use local cache that's part of the >>> configuration you need to do during setup. >>> >>> >> Hi Igor, I am not referring to LVM's metadata cache. I speak about the >> kernel I/O buffers (ie: the one you can see from "free -m" under the buffer >> column) which, in some case, work similarly to a "real" pagecache. >> >> Well don't see how is this directly related to dual-primary setup since > even with single primary what ever is not yet committed to disk is not > replicated to the secondary as well. So in case you loose the primary what > ever was in its buffers at the time is gone as well. > > > But the rule-of-thumb lets say would be to have as less cache layers as > possible without impact on the performance and retain the data consistency > in the same time. With VMs you have additional cache layer in the guest as > well as the one in the host. There are many documents discussing cache > modes like these https://www.suse.com/documentation/sles11/book_kvm/ > data/sect1_1_chapter_book_kvm.html, https://www.ibm.com/support/ > knowledgecenter/en/linuxonibm/liaat/liaatbpkvmguestcache.htm, > https://pve.proxmox.com/wiki/Performance_Tweaks for example. > > So which write cache mode you will use really depends on the specific > hardware you use, the system amount of RAM, the OS sysctl settings (ie how > often you flush to dis, params like vm.dirty_ratio, > vm.dirty_background_ratio etc.), the disk types/speed, the HW RAID > controller (for example with battery backed cache or not) ie DRBD has some > tuning parameters like: > > disk-flushes no; > md-flushes no; > disk-barrier no; > > which makes it possible to use the write-back caching on the *BBU-backed* > RAID controller instead of flushing directly to disk. So many factors are > in play but the main idea is to reduce the number of caches (or their > caching time) between the data and the disk as much as possible without > loosing data or performance. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170727/0e318c5e/attachment.htm>