On 07/21/2018 02:54 PM, Andrew Lutomirski wrote: >>>> On Jul 15, 2018, at 5:47 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: >>>> >>>> On Fri, Jul 13, 2018 at 04:05:42PM +0200, Mikolaj Izdebski wrote: >>>> On 07/12/2018 10:17 PM, Richard W.M. Jones wrote: >>>> 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. >> >> In this case my preferred advice would be: DO NOT use cache=unsafe. >> >> We've only tested scenarios for very short-lived build or temporary >> VMs (for example when I was building RISC-V packages before we had >> Koji, I used a script which created a VM per build and there it made >> sense to use cache=unsafe). >> >> I do not think it's a good idea to be using this for VMs which are in >> any way long-lived as there could be unforeseen side effects which I'm >> not aware of and certainly have never tested. >> >>> 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. >> >> Host crash => yes you'd definitely need to reinstall that VM. >> >> It's not a worst case, a host crash would near-definitely corrupt a VM >> that was ignoring flush requests. It might even corrupt in an >> undetectable way (eg. throwing away data while leaving metadata >> intact). > > Would it make sense to boot the builders with -snapshot and > cache=unsafe? After all, during normal operation, they don’t need to > persist anything. I don't think thats at all worth it for a slight bit of build speed. > > It might even be reasonable to reboot the VMs after every single build. Well, koji has no ability to do that currently, and note that some builders can in fact be doing multiple builds at once, so you would need to make sure all in progress builds were done and no new ones arrived, etc. There was a project a while back to make koji builders more dynamic (I think by making them cloud instances), but I am not sure whatever happened with it. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/R5QMWYW7TG6WETXBFGEUE6T6YPVMX32J/
