On 07/12/2018 10:17 PM, Richard W.M. Jones wrote: > On Thu, Jul 12, 2018 at 02:10:37PM -0400, Cole Robinson wrote: >> On 07/11/2018 04:37 PM, Kevin Fenzi wrote: >>> On 07/11/2018 12:57 PM, Mikolaj Izdebski wrote: >>>> On 07/11/2018 09:26 PM, Kevin Fenzi wrote: >>>>> I don't see the cache=unsafe anywhere (although the name sure makes me >>>>> want to enable it for official builds let me tell ya. ;) Can you point >>>>> out more closely where it is or docs for it? >>>> >>>> cache=unsafe is documented at [1]. (Basically, in virt_install_command >>>> you append ",cache=unsafe" to --disk parameter, next to "bus=virtio".) >>>> It makes buildvmhost cache all disk operations and ignore sync >>>> operations. Similar to nosync, but does not work on buildhw, works on >>>> virthost level, applies to all operations, not just dnf. >>>> >>>> [1] >>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_tuning_and_optimization_guide/index#sect-Virtualization_Tuning_Optimization_Guide-BlockIO-Caching >>> >>> Ah, I see at the vm level. Yeah, I don't think this would be very much >>> of a win for us. The x86_64 buildvm's have all their storage on iscsi, >>> the arm ones have their storage on ssd's. I suppose it could help the >>> ppc64{le} ones, they are on 10k sas drives. I'm pretty leary of enabling >>> anything called 'unsafe' though. >> >> I think it's unsafe only in the case of on-disk consistency, so across >> VM reboots. I _think_ over a single run of a VM it's safe, which may >> describe koji usage. >> >> I know rjones has looked deeply at qemu caching methods for use in >> libguestfs so maybe he can comment, CC'd > > I cover caching modes about half way down here: > > > https://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/
Thanks Richard, your expert opinion is appreciated. > First off, cache=unsafe really does improve performance greatly, I > measured around 25% on a disk-heavy workload. > > Does each build start with its own fresh VM? Do you care about the > data in that build VM if either qemu or the host crashes? If the > answers are 'Yes' and 'No' respectively to these questions then IMHO > this is the ideal situation for cache=unsafe. The answers are 'No' and 'Not much'. 1. VMs are installed once and are running for week/months until they are reinstalled. In the meantime guests and hosts are rebooted during routine maintenance, to apply updates. 2. There would be no data loss in case of host or hypervisor crash. Worst case, if guest operating system was corrupted sysadmins would need to trigger VM install. > > The caveats: > > If qemu or the host crashes, the disk image underlying these VMs will > (like 99.9% certainty) be corrupted. Even 'sync' inside the VM will > not do what you expect, it is just ignored. It's NOT a good idea on > VMs which are used for long periods when the host might reboot during > that time. It's NOT a good idea if you deeply care about the data in > the disk image. We do run guests for long time and reboot hosts. But I think there is no danger if you ensure that guest OS is shut down cleanly before host reboot. > It should only be used when the VM data can be recreated from scratch. This is the case of Koji builders. They don't contain any special data, just operating system and configuration that can be recreated easily. > > In libguestfs we use cachemode.*unsafe in a few places, carefully > chosen, when the above conditions apply. > https://github.com/libguestfs/libguestfs/search?q=cachemode+unsafe&unscoped_q=cachemode+unsafe > > Rich. > -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SXNS4V7XAS4F6QF5RBWBDTVLXCP5S5TA/
