Re: [lmi] [lmi-commits] master b80b1ae 7/7: Experiment with bind mounts

[Greg Chicares]

On 2019-10-04 23:29, Vadim Zeitlin wrote:
> On Fri,  4 Oct 2019 19:21:00 -0400 (EDT) Greg Chicares <address@hidden> wrote:
> 
> GC> branch: master
> GC> commit b80b1ae2edfabd6eb84a9c2db1320a64085674e8
> GC> Author: Gregory W. Chicares <address@hidden>
> GC> Commit: Gregory W. Chicares <address@hidden>
> GC> 
> GC>     Experiment with bind mounts
> GC>     
> GC>     It takes a little over forty minutes to run 'install_centos.sh'.
> GC>     Perhaps it would be faster if the host system's /var/cache could
> GC>     be used for apt and yum inside the (nested) chroots.
> 
>  FWIW I don't think there is any noticeable overhead with accessing the
> disk inside chroot.

Yes, I would certainly expect no overhead, no matter how deeply
the chroots are nested. That's an enormous advantage compared to
what I used to do with qemu-kvm msw VMs, although much of the
slowdown in that case was probably due to the poor drivers for
emulating msw-xp's ntfs. And chroots are just transparent sets
of files, whereas my VMs were opaque multiple-GiB blobs.

> I rarely have the exact same versions of anything
> inside and outside of chroot (this is the point of having chroot in the
> first place...), but right now I have gcc 8.3 in both the main system and
> chroot and building wx with it takes the same amount of time in both cases.

OTOH, I suspect that you set up a chroot once, adjust and tune
it until it works, and then use it for a particular purpose;
but my use case is different...

>  Or perhaps I misunderstood you and you planned to use the host system file
> system as a cache between the different runs of the script? In this case,
> it would help, of course, so please just ignore this message then.

...in exactly that way. I've created and destroyed this nested
pair of chroots at least two dozen times over the last few days.
My CPUs and SSD are fast, but my DSL is slow, so bind-mounting
persistent directories on my "host" as (paraphrasing for clarity
and terseness)
  /src/chroot/centos/var/cache/yum
  /src/chroot/centos/srv/chroot/debian/var/cache/apt
has enabled me to get the total elapsed time down to 00:30:37,
for creating the debian-within-centos-within-debian chroot and
building lmi (and all libraries) therein for 32- and 64-bit msw
both. Now I'm almost ready for the final step: repeating the
process for a debian-within-redhat chroot on a corporate server.

I've learned a lot along the way. Somehow I managed to create
a set of bind mounts that seemed circular, but now I know how
to detect and avoid that. I also managed to blow out dbus, so
that I couldn't even run 'reboot' until I logged completely out
as my normal user and back in as root; that seems funny now,
though it didn't exactly feel that way at the time. At least I
didn't have to use my magic Left-Alt-SysReq powers.