Re: [HEADS UP] Removal of GCC from the buildroot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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).

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/NYD2UNKQPIOK663RXSQCPVCWMSBFPXGI/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux