public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Uladzimir Bely <ubely@ilbers.de>
To: Henning Schild <henning.schild@siemens.com>
Cc: isar-users@googlegroups.com, "Schmidt,
	Adriaan (T CED SES-DE)" <adriaan.schmidt@siemens.com>
Subject: Re: [PATCH 1/1] sstate: compress rootfs sstate files
Date: Thu, 24 Feb 2022 06:55:41 +0300	[thread overview]
Message-ID: <25321236.1r3eYUQgxm@home> (raw)
In-Reply-To: <20220223223306.7b74e270@md1za8fc.ad001.siemens.net>

In the email from Thursday, 24 February 2022 00:33:06 +03 user Henning Schild 
wrote:
> Am Wed, 23 Feb 2022 18:52:54 +0300
> 
> schrieb Uladzimir Bely <ubely@ilbers.de>:
> > In the email from Wednesday, 23 February 2022 18:43:21 +03 user
> > 
> > Henning Schild wrote:
> > > This is wrong. Everything you put into sstate is already compressed
> > > there.
> > > 
> > > So what you probably want is to "move" stuff into sstate and delete
> > > setscene after unpack so temporary tarballs maybe do not hang
> > > around.
> > > 
> > > That will save much more space and time, but i am not sure it would
> > > be "allowed". That is why i added Adriaan on cc.
> > 
> > Yes, it may be wrong because this tarballs might be needed to compare
> > hashes by sstate. But why not use them already compressed and save
> > space in workdirs?
> 
> The real way to save the space is to not keep sstate stuff at all (in
> WORKDIR). When putting things into sstate we should remove it from
> WORKDIR right after it went into sstate. When getting stuff out we
> should remove staging stuff at the end of setscene.
> 
> SSTATE_BUILDDIR seems to take care of some of the bits, i did not
> manage to write the correct code for all of that. But compressing bits
> we do not actually want to keep does not seem right.
> 

I also tried to remove these files, but didn't succeed. It's easy to do for 
getting stuff from sstate cache - we can just remove .tar file at the end of 
*_setscene(). But it's a bit more tricky, when we put stuff to sstate cache - 
it's the last stage and we can't execute any custom code. Even [postfuncs] are 
executed before sstate cache is created.

Probably, additional task for cleanup sstate dir could be used. For example,
do_bootstrap => (do_bootstrap_sstate_cleanup) => do_build.

> So a clear NACK from me.
> 
> Henning
> 
> > > Henning
> > > 
> > > Am Wed, 23 Feb 2022 10:17:49 +0100
> > > 
> > > schrieb Uladzimir Bely <ubely@ilbers.de>:
> > > > This saves about 1-2 GiB per multiconfig, at the expense of
> > > > approximately 20-40 seconds for packing the files.
> > > > 
> > > > Signed-off-by: Uladzimir Bely <ubely@ilbers.de>
> > > > ---
> > > > 
> > > >  meta/classes/rootfs.bbclass                         | 4 ++--
> > > >  meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 4 ++--
> > > >  2 files changed, 4 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/meta/classes/rootfs.bbclass
> > > > b/meta/classes/rootfs.bbclass index 2bdb3b6d..15e87bec 100644
> > > > --- a/meta/classes/rootfs.bbclass
> > > > +++ b/meta/classes/rootfs.bbclass
> > > > @@ -298,13 +298,13 @@ do_rootfs_install[sstate-interceptfuncs] =
> > > > "rootfs_install_sstate_prepare" # the buildchroot is owned by
> > > > root, so we need some sudoing to pack and unpack
> > > > rootfs_install_sstate_prepare() { sudo mount --bind
> > > > ${WORKDIR}/rootfs ${WORKDIR}/mnt/rootfs -o ro
> > > > -    sudo tar -C ${WORKDIR}/mnt -cpf ${ROOTFS_SSTATE}/rootfs.tar
> > > > --one-file-system rootfs
> > > > +    sudo tar -C ${WORKDIR}/mnt -cpzf
> > > > ${ROOTFS_SSTATE}/rootfs.tar.gz --one-file-system rootfs sudo
> > > > umount ${WORKDIR}/mnt/rootfs
> > > > 
> > > >  }
> > > >  do_rootfs_install_sstate_prepare[lockfiles] =
> > > > 
> > > > "${REPO_ISAR_DIR}/isar.lock"
> > > > 
> > > >  rootfs_install_sstate_finalize() {
> > > > 
> > > > -    sudo tar -C ${WORKDIR} -xpf ${ROOTFS_SSTATE}/rootfs.tar
> > > > +    sudo tar -C ${WORKDIR} -xpzf ${ROOTFS_SSTATE}/rootfs.tar.gz
> > > > 
> > > >  }
> > > >  
> > > >  python do_rootfs_install_setscene() {
> > > > 
> > > > diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> > > > b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc index
> > > > 2f483f5a..99d1d945 100644 ---
> > > > a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc +++
> > > > b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc @@ -402,11
> > > > +402,11 @@ do_bootstrap[sstate-plaindirs] = "${BOOTSTRAP_SSTATE}"
> > > > do_bootstrap[sstate-interceptfuncs] = "bootstrap_sstate_prepare"
> > > > 
> > > >  bootstrap_sstate_prepare() {
> > > > 
> > > > -    sudo tar -C $(dirname "${ROOTFSDIR}") -cpf
> > > > ${BOOTSTRAP_SSTATE}/bootstrap.tar --one-file-system $(basename
> > > > "${ROOTFSDIR}")
> > > > +    sudo tar -C $(dirname "${ROOTFSDIR}") -cpzf
> > > > ${BOOTSTRAP_SSTATE}/bootstrap.tar.gz --one-file-system $(basename
> > > > "${ROOTFSDIR}") }
> > > > 
> > > >  bootstrap_sstate_finalize() {
> > > > 
> > > > -    sudo tar -C $(dirname "${ROOTFSDIR}") -xpf
> > > > ${BOOTSTRAP_SSTATE}/bootstrap.tar
> > > > +    sudo tar -C $(dirname "${ROOTFSDIR}") -xpzf
> > > > ${BOOTSTRAP_SSTATE}/bootstrap.tar.gz sudo ln -Tfsr "${ROOTFSDIR}"
> > > > "${DEPLOY_ISAR_BOOTSTRAP}" }


-- 
Uladzimir Bely




      reply	other threads:[~2022-02-24  3:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23  9:17 [PATCH 0/1] " Uladzimir Bely
2022-02-23  9:17 ` [PATCH 1/1] " Uladzimir Bely
2022-02-23 15:43   ` Henning Schild
2022-02-23 15:52     ` Uladzimir Bely
2022-02-23 21:33       ` Henning Schild
2022-02-24  3:55         ` Uladzimir Bely [this message]

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=25321236.1r3eYUQgxm@home \
    --to=ubely@ilbers.de \
    --cc=adriaan.schmidt@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    /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