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/ 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 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. It should only be used when the VM data can be recreated from scratch. 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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/CXOTYCK3WEZTRLBQTM7N3F4JGSOTZ2NR/
