Hello everyone, I've tried just about everything the last weeks and my findings are: - the problem with LVM cache seems NOT to be caused by KVM/qemu. But is /seems/ that it is noticeable more inside a KVM. So the slowdown of the cache also happens on HW-node, but you must give it a serious go before you notice. - Not a single time I succeeded in creating a well working cache using LVM2 cache. In artificial / KVM setups and with *small* devices it works (dm-testsuite etc). But in real life scenario with *fully population all the PV's* on 2TB HDDs and 250G SSDs (both RAID 1) the cache stopped working after 20 - 50 GB of writes although the cache is 150+G large. Please use fio examples below and always use new filenames so not the same blocks are overwritten. The poor performance stayed most of the time even when all blocks were flushed. Very unpredictable cache performance / behavior. I finally decided to go for dm-writeboost in stead of lvm2 cache (dm-cache). This was the only way to create a well working cache that works till 95% filled. But of course would be nicer to have something that generally more stable like LVM2. I guess in the sens of this mailing-list this issue is resolved because it does not seem to belong here. -- Met vriendelijke groet, Richard Landsman http://rimote.nl T: +31 (0)50 - 763 04 07 (ma-vr 9:00 tot 18:00) 24/7 bij storingen: +31 (0)6 - 4388 7949 @RimoteSaS (Twitter Serviceberichten/security updates) On 04/20/2017 04:23 PM, Sandro Bonazzola wrote: > > > On Thu, Apr 20, 2017 at 12:32 PM, Richard Landsman - Rimote > <richard at rimote.nl <mailto:richard at rimote.nl>> wrote: > > Hello everyone, > > Anybody had the chance to test out this setup and reproduce the > problem? I assumed it would be something that's used often these > days and a solution would benefit a lot of users. If can be of any > assistance please contact me. > > I haven't seen any additional report of this happening, can you please > try to reproduce with the new qemu-kvm-ev-2.6.0-28.el7_3.9.1 currently > in testing? > > -- > Met vriendelijke groet, > > Richard Landsman > http://rimote.nl > > T: +31 (0)50 - 763 04 07 > (ma-vr 9:00 tot 18:00) > > 24/7 bij storingen: > +31 (0)6 - 4388 7949 > @RimoteSaS (Twitter Serviceberichten/security updates) > > > > > -- > > SANDRO BONAZZOLA > > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > > Red Hat EMEA <https://www.redhat.com/> > > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > > > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > https://lists.centos.org/mailman/listinfo/centos-virt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20170526/683c3bbd/attachment-0003.html>