public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
To: "Moessbauer, Felix" <felix.moessbauer@siemens.com>
Cc: "ubely@ilbers.de" <ubely@ilbers.de>,
	 "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"Kiszka, Jan" <jan.kiszka@siemens.com>,
	 "Schild, Henning" <henning.schild@siemens.com>
Subject: Re: [PATCH v3 0/5] Improving apt cache
Date: Mon, 30 Jan 2023 10:56:13 +0100	[thread overview]
Message-ID: <CAJGKYO5miBxt5=G5z1Ga9shN50SZ=Ls-gas3qiau4CRS80Z_dw@mail.gmail.com> (raw)
In-Reply-To: <cac52c2157515ae646f5a04a80a3d77beeb11104.camel@siemens.com>

On Mon, 30 Jan 2023 at 09:45, Moessbauer, Felix
<felix.moessbauer@siemens.com> wrote:
>
> On Fri, 2023-01-20 at 08:31 +0100, Uladzimir Bely wrote:
> > Currently, apt cache (e.g. `var/cache/apt/archives`) import and
> > export
> > functions are not optimal. Multiple files are copied from global
> > DL_DIR to package WORKDIR, increasing disk IO and space needed.
> >
> > Also, various chroots (bootstrap, buildchroot, sbuild chroot) include
> > their apt caches to sstate cache files.
> >
> > This patchset switches to hardlinks instead of copies and removes apt
> > cache from bootstrapped images ans sstate caches.
>
> I just saw that this pattern does NOT work in case the cache is on a
> different filesystem. This unfortunately is the case for all CI systems
> with locally mounted caches, as well as for kas-container builds with
> DL_DIR outside the KAS_WORK_DIR.

The entire cache system needs to be reworked and this was pretty
clear. However, every step (hard link included) brings us nearer to
this conclusion and moreover it helps to reduce the building time (now
11m29s on complete image) that allows us to perform more tests in less
and lesser time. I am currently on this and I have a good feeling that
I will reach a general solution soon. As you can imagine the cash
system is not an easy piece to rework due to its implications in many
different starting points it can have. So, build and rebuild are just
two basic cases but variations of the top or ISAR layers that cause a
partial rebuilding and breaks in building are many other cases.
Obviously the main idea is to reach a reasonable goal AND then break
it in several small steps that can be integrated upstream because a
single large patch would be equivalent to fork another 'next' branch
which is possible but IHMO not acceptable for a long time. After all,
also the GPLv3 on composition is not a long-term way to go. So, in the
best case it makes sense that we reach the common goal to rationalise
and speed-up the cache subsystem.

Best regards, R-

  reply	other threads:[~2023-01-30  9:56 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20  7:31 Uladzimir Bely
2023-01-20  7:31 ` [PATCH v3 1/5] Clean apt cache from debootstrapped rootfs dirs Uladzimir Bely
2023-01-20  7:31 ` [PATCH v3 2/5] Use hardlinks in deb-dl-dir import/export Uladzimir Bely
2023-01-20  7:31 ` [PATCH v3 3/5] Exclude apt cache from sstate caches Uladzimir Bely
2023-01-20  7:31 ` [PATCH v3 4/5] Use symlinks when importing debian packages to sbuild chroot Uladzimir Bely
2023-01-20  7:31 ` [PATCH v3 5/5] Lightweight copy of rootfs directories if possible Uladzimir Bely
2023-01-20 13:04 ` [PATCH v3 0/5] Improving apt cache Moessbauer, Felix
2023-01-21  4:12   ` Roberto A. Foglietta
2023-01-24  7:38 ` Uladzimir Bely
2023-01-30  8:45 ` Moessbauer, Felix
2023-01-30  9:56   ` Roberto A. Foglietta [this message]
2023-01-30 10:04     ` Roberto A. Foglietta
2023-01-30 10:45   ` Henning Schild
2023-01-30 12:24     ` Roberto A. Foglietta
2023-01-30 14:16   ` Roberto A. Foglietta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJGKYO5miBxt5=G5z1Ga9shN50SZ=Ls-gas3qiau4CRS80Z_dw@mail.gmail.com' \
    --to=roberto.foglietta@gmail.com \
    --cc=felix.moessbauer@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=ubely@ilbers.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox