>> On Jul 15, 2018, at 5:47 AM, Richard W.M. Jones
<rjones(a)redhat.com> 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.
It might even be reasonable to reboot the VMs after every single build.